What Makes Good Software?

Before we begin designing software, it is worth asking a simple question:

What makes software good?

At first glance, this might seem like an easy question to answer. Most of us have used software that we enjoy and software that we would rather never use again. We often have a sense of what feels intuitive, useful, reliable, or frustrating.

The challenge is that “good software” means different things to different people.

A user might define good software as something that is easy to learn and helps them accomplish their goals efficiently. A client might focus on whether the software solves the intended problem while remaining within budget and timelines. A developer may care about whether the code is organized, maintainable, and easy to modify. Testers might value reliability and consistency, while regulators may focus on privacy, accessibility, or safety.

All of these perspectives are valid.

As software designers, one of our responsibilities is to recognize that software exists within a larger ecosystem of people, organizations, technologies, and regulations. Good software is rarely defined by a single characteristic. Instead, it emerges when a system successfully balances many different needs and expectations.

Looking Through Different Lenses

Think about a piece of software that you use regularly. It might be a banking app, a social media platform, a learning management system, or even a game.

Now consider how different people might evaluate that software:

• A user may ask whether it is easy to use.
• A client may ask whether it solves the intended problem.
• A developer may ask whether it can be maintained over time.
• A tester may ask whether it behaves reliably under different conditions.
• A government agency may ask whether it meets legal requirements.
• An accessibility advocate may ask whether everyone can use it regardless of ability.

Notice that these perspectives are not necessarily in conflict. Instead, they help us understand the many dimensions that contribute to successful software.

Throughout this course, we will explore how software designers balance these perspectives while developing systems that meet real-world needs.

Three Foundations of Good Software

While every project is unique, most successful software systems are built upon three broad categories of requirements:

1. General Requirements
2. Legal Requirements
3. Specific Requirements

Together, these help define what a successful solution looks like.

General Requirements

Some requirements apply to almost every software project, regardless of the problem being solved.

These requirements often focus on qualities that make software easier to build, maintain, test, and improve over time. Examples include:

• Readable code
• Clear documentation
• Maintainability
• Testability
• Reliability
• Portability

These qualities may not always be visible to users, but they play an important role in determining whether software remains useful over months or years.

Imagine inheriting a software system that contains no comments, inconsistent naming conventions, and little documentation. Even if the software currently works, making changes would be difficult and expensive. Good software considers not only the needs of today’s users but also the needs of future developers.

Legal Requirements

Software does not exist outside the law.

Depending on where software is developed, distributed, or used, there may be legal requirements that influence design decisions. These requirements help protect individuals, organizations, and society more broadly.

For software developed in Ontario and Canada, several important pieces of legislation commonly affect software design:

• Accessibility for Ontarians with Disabilities Act (AODA)
• Personal Information Protection and Electronic Documents Act (PIPEDA)
• Canada’s Anti-Spam Legislation (CASL)

Accessibility and Inclusion

The Accessibility for Ontarians with Disabilities Act (AODA) was introduced in 2005 to improve accessibility for people with disabilities.

For software designers, this means considering how people with different abilities interact with technology. Accessibility considerations may involve:

• Visual impairments
• Hearing impairments
• Motor impairments
• Cognitive differences
• Temporary injuries or limitations

Accessibility is not simply about compliance. It is about ensuring that technology can be used by as many people as possible.

Later in this course, we will explore accessibility considerations in greater detail and discuss how accessibility can be incorporated into software design from the beginning of a project.

Privacy and Personal Information

The Personal Information Protection and Electronic Documents Act (PIPEDA) establishes rules for how organizations collect, use, and manage personal information.

Whenever software collects information about users, privacy considerations become important. Designers must think carefully about what information is collected, why it is collected, how it is stored, and who has access to it.

Communication and Consent

Canada’s Anti-Spam Legislation (CASL) helps protect Canadians from unwanted electronic communications.

If software sends emails, notifications, newsletters, or other electronic messages, designers must understand the responsibilities and restrictions associated with these activities.

A Moving Target

One important reality of software development is that laws and regulations change.

As a software professional, part of your responsibility is staying informed about new legislation, evolving standards, and emerging expectations that may affect the systems you design.

Specific Requirements

General requirements help us build quality software. Legal requirements help us build compliant software.

Specific requirements help us build the right software.

Specific requirements describe what a system must do in order to solve a particular problem. They define the needs that the final solution must satisfy.

Importantly, requirements describe what is needed, not how it should be built.

Consider the difference between these two statements:

• “The system shall allow users to create an account.”
• “The system shall use a blue button in the top-right corner to create an account.”

The first statement describes a requirement. The second begins describing a specific implementation.

As software designers, our goal is to understand the problem before deciding on the solution.

Requirements Are Not Instructions

A useful way to think about requirements is to compare them to instructions.

Instructions

Instructions explain how to complete a task.

A recipe tells you how to bake a cake. If multiple people follow the same recipe using the same ingredients, the outcomes should be very similar.

Requirements

Requirements explain what is needed.

They define the problem rather than prescribing a single solution.

Multiple solutions may satisfy the same requirement, and some solutions may be better than others depending on the context.

This distinction is important because software design is fundamentally a problem-solving activity. If we jump too quickly to implementation details, we risk overlooking better solutions.

Where Do Requirements Come From?

Requirements do not appear magically.

They emerge through research, observation, conversation, and investigation.

In software design, research may include:

• Academic literature and scholarly research
• Industry reports and professional publications
• Discussions with clients and domain experts
• Interviews with users
• Observations of existing workflows
• Surveys, focus groups, or usability studies

In CIS3750, most of your work will focus on learning from people.

You will interact with community partners, clients, users, and teammates. You will learn how to ask questions, gather information, identify needs, and translate those needs into meaningful software requirements.

This process takes time and practice. It is also one of the most valuable skills a software designer can develop.

Building Good Software

Understanding requirements is only part of the challenge.

Creating good software also requires strong professional skills.

Successful software developers continuously develop:

• Technical skills and coding expertise
• Communication skills
• Planning and organizational skills
• Teamwork and collaboration skills
• Critical thinking and problem-solving skills

By the time you reach CIS3750, we assume you have already developed a foundation in programming and continue to strengthen those skills.

The primary focus of this course is not learning another programming language or framework.

Instead, CIS3750 focuses on the skills that allow teams to transform complex problems into meaningful software solutions.

Throughout the semester, you will practice communicating with clients, collaborating with teammates, organizing requirements, planning development work, and making design decisions in situations where there is rarely a single correct answer.

These skills are often what separate software that merely works from software that truly succeeds.