In Software, Good Design is Everything
Designing is one of the most important and overlooked areas of a programming project. After all, how important it is creating a UML diagram if it will not be used during the coding of the system? On the other hand, stop and think about the good software that you have used, such as vim or UNIX. What do they have in common? The unsurprising answer is: they have good design.
Designing software is not the same as creating nice UML diagrams. I know a lot of programs that have beautiful UML diagrams but are terribly bad designed. On the other hand, some of the most interesting architectures were not created from an UML diagram. From a pragmatic perspective, having a good design means that the resulting architecture provides the basic mechanisms for extending the original program without the need to rewrite its basic components.
In a well design program, developers can feel confident to extend the system, without thinking that they need to understand something very subtle about its internals. For example, very few people need to know how UNIX is internally implemented in order to write a new application. You also don’t need to know the internal architecture of Emacs to create a new package. These are examples where a system possess a strong technical foundation to which additional functionality can be easily added.
On the other hand, a badly designed piece of software can have growing costs that will continue forever as long as changes are necessary. If there is any need for extension in such a system, then one has to understand how each piece works together. Working in this way is like playing with a house of cards: for lack of a foundation, any change in the system can bring the whole thing down.
Moreover, even if no further extension is required, think about the costs of maintaining a low quality system like this. In general, what this means is removing bugs that will inevitably appear from time to time. In a badly designed software, high attention to detail is necessary to avoid a mess that may be eventually caused by the addition of a single instruction.
This kind of flakiness in software is what costs so much time and money on common projects. Many such projects start with the explicit (and misplaced) goal to create a program quickly. However, not spending the time on design may have bad consequences for the future of a project. If the basic architecture is not in place, it becomes increasingly difficult to make changes, and huge amounts of time are lost during the main parts of the project.
The lesson from these observations is that everything starts with good design. If your software doesn’t have a good design, it is doomed. Even though there is a huge pressure to create software quickly, the initial design is the most important part of the process. Skipping this step can hinder the whole effort and turn your project into another nightmare, that is sadly so common on software shops.
Further Reading
The mythical man-month is the classic book on design issues on software engineering. I highly recommend it for anyone interested in software design.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
Yep, everyone underestimates the value of good design until they reach the point where adding new features becomes a real challenge, and need to spend a big amount of time on a huge refactoring.
By Pablo on Mar 18, 2010