Software generally falls into three categories: user-centered, semi-automated, or completely automated.

User-centered software includes an interface where users will interact with the software to produce the desired results. In cases where you’re creating user-centered software, you’ll want to consider user experience as the first step in your software design process. Understanding how users will interact with the software will help you determine what functionality to build and how it should connect with the interface and the user’s inputs. Typically, user-centered design involves storyboarding the reasons a user uses your software and how they’d expect to interact with the software.

On the other end of the spectrum, completely automated software has no user or interface. It’s software that talks to other software. You won’t need a storyboard in these cases, but you’ll want to map all the components out in a flow chart to organize the various components. Sequence diagrams are also a helpful way of documenting the various communications between systems.

A semi-autonomous piece of software sits in-between. You’ll need to consider both the user’s interaction with the software and the autonomous processes that are happening as you architect a solution.

One of the reasons good software design is so important is that the demands on software are always changing. As a result, requirements constantly change as well. Sometimes a client needs new features. Other times you may want to change the libraries or tools you use to accomplish a given task. In fact, in the agile world, we commit to delivering a small set of features and functionality in our given iteration, and we allow requirements to change if those changes do not interfere with our current sprint commitment. Ultimately, over time, all software becomes legacy and needs updates to keep up with new business needs or technology best practices.

The challenge about designing software from the beginning of a project is the future needs may not be clear at the outset. Software design best practices anticipate a variety of future needs. It implements best practices from the beginning, instead of hacking together a solution every time a new problem arises.

The foundation of good software design is a separation of concerns. This means that you divide your software into component parts and build each part once. Avoid code repetition. Always place code that you’re likely to use again in a utility class and make it accessible throughout the application. When you need to update that code in the future, you only need to edit it in one place, instead of searching for the various locations where you repeated the code.

When you need a given component, you can call it and use it in an abstraction layer. This separation is called modularity, and it’s a key to scalable, maintainable software architecture.

Modularity has several key benefits:

Testing & Debugging

Since each component is self-contained, you mitigate dependency issues. It becomes easy to test each component in isolation by using a mocking or isolation framework.. This helps us track down bugs and other problems more quickly. It also allows you to divide work among developers, since each component stands on its own.

Reusability

Another benefit of modularity is reusing the code becomes easy. If you discover you need the same functionality in a new project, you can package the existing functionality into something reusable by multiple projects without copying and pasting the code. This can be accomplished with a web service or a nuget package for example.

Extensibility

Your software now runs as a set of independent components connected by an abstraction layer. This means adding new capabilities is as easy as creating a new component and linking it to the abstraction layer. Incorporating new features is trivial if you’ve architected the application well.

If each component runs in a modular container, you’ll need an overarching abstraction layer. The abstraction layer is where the user will interact. Based on the user’s inputs, the abstraction layer will decide which components are needed to fulfill the task. In simple terms, the code that does the work should be separate from the code that serves the features to the user.

We use this approach so that a change in one place won’t necessarily break other parts. Your abstract layer is not likely to change as often as your low-level modules. They’ll get updated, added to, and revised much more frequently. Since they’re contained, a mistake in an update won’t necessarily break the whole application, just the one module. Each module knows about the other modules in the application and what they do. However, it doesn’t know how the other modules do their work.

The goal of software design is simplicity. Each class, method, and module in your code should have a single purpose. Every new task should get its own module that we can use and modify independently. By giving each module a task, you minimize regressions and makes the code easier to use.

Embrace simplicity, don’t add complexity where a simpler solution will work. Often, it’s tempting to think you have a brilliant solution, but if there’s a simpler way to accomplish the same task, you should always choose the simpler solution.