Every programmer starts her career with something small. Implement a small function. Then implement a couple of functions talking to each other. Then implement a module, with dozens of functions, and maybe error handling and an API.

But sooner or later, we all want to move on and to step up to the higher abstraction level. We want to oversee the whole software system. We want to learn how to design it – how to do software architecture. But because this is our first time when we are stepping up one abstraction level higher, it is often very hard to do. Where can I start? When am I finished? How do I know I’ve created a right architecture?

Teachers and universities often don’t help but instead make things even worse, because they overload us with huge amount of information and detailed requirements about the architecture.

Meanwhile, there is only one thing about software architecture that is really important.

Architecting software is like caring for your child.

You want that your child will be safe and healthy; and that he will be loved, and have a long and happy life.

Safety. Your software might crash in run-time, or destroy valuable data. If it depends on its environment (other software or hardware) to run – teach your software, how to recover, when its environment fails. Teach your software, how to protect against the input from hackers and unprofessional users. Teach your software to change or produce data, only if it is fully sure it is working correctly. Teach your software, how to sacrifice one part of it to protect the whole, and teach it to run without one of its parts.

Health. Obesity is the most important problem for software. Always try to implement the same functionality with less code. Do not implement functionality, which nobody needs, but do prepare the software for the challenges it will definitely expect in the future – plan for extensibility. Use refactoring to avoid code areas that nobody is able to understand and to change, because these are the dead areas of the software body, limiting its flexibility.

Software is often created it teams. You want that the other team members love and care about the software as you do. Make sure that everyone writes code that can be read by anyone – force a uniform programming style if needed. Ensure that it is safe for team members to use the code of other team members – no unexpected results, proper error handling, consistent conventions. Avoid code ownership, because you want to get a lovely software system, and not just a set poorly interconnected moving parts.

For software to have a happy life, it must be loved and used by users. Ensure you not only understand the software requirements, but also why the users have these requirements. Work with the users to define even better requirements, which will make your software faster, slimmer or robuster. Come up with the ideas how to make your software even more lovable – a successful software will get more loving and motivating hands to work on it, while an unsuccessful software will be abandoned and die.

It is not easy to care for a child, nor it is easy to create a good software architecture. There is no rules equally suitable for all children – every time you will have to find a proper answer, may be by trial and error. But the results of the job done right might make you equally proud and your life fulfilled.