Recently I finished a course about software architecture. In that course they talked about some key concepts that should be taken in account when designing software systems, and documents that are the result of summarizing all the considerations and requirements.
My main goal was to improve how I design systems and make them more performant and secure. But after taking the course I realized how useful design documents really are at many levels. If you, like I did, don't give the real importance that this effort have in the success of your software projects, let me show you how a good software design effort can help you in succeed with your projects.

Easier to build, easier to validate.

When building a design document, you are focusing only on one part of the problem. This has several advantages, but the most remarkable is that it makes things easier because this process divides the work in smaller tasks that can be accomplished step by step, allowing focusing on solving the big picture first.

When developing a project, sometimes the issue that might arise is not technical, but functional. Let's picture this with an example: imagine that you are developing an app that allows users to create groups to share expenses. You start designing the SQL schema, the SQL statements that allow the software to link users and expenses and then you find out that it would be a good idea to allow non-users to be part of the expenses because you don't want to force users to create an account. Then you have to redo some work that is no longer useful, wasting time and resources, changing not only the code, but the database schema among other things.

During the planning stages, it is easier to change and model things, because at earlier stages there is usually less work to do and you have the big picture in mind, making this effort more efficient. Also, having the big picture right in front of you instead on being focused on each piece makes it easier to validate the interactions between all the pieces and components of the software itself.

Design documents lead you through the process.

This might be obvious, but sometimes it seems to be a good idea to start working and solve problems when they start appearing. Don't get me wrong, this approach is valid when working with small projects, and sometimes this is the only way to work, but if you have big plans for the project, a proper design document will help you to succeed in building your project. It will guide you when you are stuck and help you to keep the big picture in sight.

But then you might think that at the end you are still investing the same amount of effort because at the end you still have to figure out the same number of things, but you will be wrong because designing first is easier than working out different things while you work on them. When designing, you focus more on the big picture, and it is easier to pinpoint interactions between components at that level, instead of doing the same while trying to debug the SQL statement. They are different tasks and the approach required to solve the task is different too.

Helps foresee future needs and problems.

When writing the software architecture document, you need to think about all the pieces that will compose the service, how they interact with each other, the requisites and limitations components impose on other systems.

At some point, a component might impose some limitations or requisites that might affect the price of keep the system running, the consumption of computing resources or the storage. This is not a problem by itself, because this can be planned and resources can be acquired when they are needed, but if the system we are building is not well designed, it would be possible that the system won't be extensible enough and it might require additional effort to improve the software, leading to service outages or degradation while the work is not finished.

With a good previous design effort, it is easier to pinpoint conflicting parts of the software, allowing the programmers to be more careful when building specific parts of the system, or start coding that part following one specific architecture that allows more extensibility at expenses of complexity. It is important to know all the requisites before choosing the trade-offs.

To illustrate this, let's imagine that we are building the previous mentioned app for expenses sharing. We thought that it would be awesome to send a picture of the bill and a computer vision program would extract the prices from the ticket. If we design properly this functionality, it is easier for us to estimate how this feature will be used, and how much it would consume from our compute resources. With this information, we can decide how this feature should be implemented: using a message queue, directly in the API call, storing in the database... Planning ahead will help us to make better decisions.

Makes progress tracking easier.

Last, but not least, by having a complete design document we can easily know what features are completed, what features are being developed and what features are missing yet. This might not seem important, but it really is.

For solo developers, keeping track of the work is useful to keep motivation because progress is a rewarding experience. In addition to this, this helps developers to know which task they have to accomplish next, reducing the sensation of wasting effort.

For teams, it helps to know which tasks are completed, which tasks are being done by the rest of teammates and which tasks are pending. This improves collaboration, and makes the team work more efficiently. Finally, having a complete design helps things to work flawlessly first time. If each team member adheres to what the design document says, the integration between software components will be easier than if each team member do their part without having the integration under the radar.

Conclusion

We saw that sometimes it is more efficient to spend extra time preparing the tasks to be done in order to reduce the overall effort. Preparing properly might help you to success in your projects, and reduces unexpected issues in the long run.

Obviously, there are more benefits than the ones showcased here, and there are also some drawbacks, but I truly believe that the extra work is worth the effort.