One of the biggest issues in developing software is how to write programs that have robust design. Robust design, of course, can have different meanings, and won’t be the same thing for everyone. However, there is the intuitive notion that software that can withstand the test of time is based on robust design.

My experience in software development has shown that many of the common notions of robustness in software design are false. For example, the idea that software has to always be reusable is a major source of problems for software architects and developers. It is a fallacy that has been promoted by vendors of new technologies, and in some way continues to be accepted without criticism.

A Few Personal Guidelines

Here is a set of guidelines that I follow when writing software, and that have proven to be much more useful in generating programs of high quality.

Implement only what you need: one of the things I try to avoid is creating software that is more general than it needs to be. If you are trying to be ahead of the development curve, there is always the risk that you will be going in the wrong direction. This happens because we can rarely be sure of the future needs of your organization.

Avoid useless abstractions: this is related to the previous topic, but deserves to be treated separately. Abstractions are useful if they simplify the way a feature is implemented. However, some abstractions exist only to satisfy the needs of developers.

This happens a lot when people start to treat everything as a design pattern, for example. Clearly, even the simplest development problems can be solved with design patterns, but they don’t need to?—?specially if this is going to turn the program into something more complicated.

Make it easy to change your implementation: at the same time, implementations should be easy to change, or even swap completely, if possible. Big abstraction can make this task harder too, so you need to be aware of the repercussions of using a more complicated data structure.

Address the main issues, avoid what is non essential: one of the big laws of programming should be: avoid doing what you don’t need to. Many developers are tempted to add features that are non-essential, but “nice” to have. The problem with this line of thinking is that nice features also takes time to test and maintain. Testing and maintenance are the biggest costs in software development, not the initial time spent on developing the feature. Anything that we can do to reduce testing and maintenance is useful, specially if we are still meeting the requirements of the project.

Avoid using components that will require effort to understand/change: Finally, although it goes contrary to the wisdom of most project managers, there are cases in which you don’t want to use a component for a project?—?even if it already exists. Some components are not written to be reused, and trying to do so only make the project more difficult to manage. If that is the case, don’t try to reuse for the sake of it?—?it is just a pointless exercise if it is not improving the productivity of the team.

Further Reading

A book that explores many of these topics (presenting real numbers) is Facts and Fallacies of Software Engineering, by Robert L. Glass.

Similar Posts:

• Day 27: Design Resilient Interfaces
• When in Doubt, Create an Interface
• Day 3: Keep a Programming Diary
• Day 5: Write a Unit Test Before Coding
• Day 29: Fix the Cause, Not the Symptom