Introduction
In my opinion, there are 5 primary software design principles, in regards to cost. As we, software developers and consultants, know very well, software development is very expensive. It is beneficial, though, to look at the costs of already deployed code. In that context, poorly written code is expensive code.
The Five Design Principles
- Readability. Code that is difficult to read is expensive to maintain. If you hired 5 Accenture developers at a cost of $200/hour and they have to spend two months figuring out your spaghetti code, it would cost you $336,000. On the other hand, if your code was intuitive, used easily recognizable paradigms, etc. and it only took them one week to figure out your code, it would only cost $80,000. What’s more is that unreadable code becomes more unreadable as time goes on. Since developers have a high turnover rate, this cost is recurring and it will grow over time.
- Maintainability/extensibility. If code lacks modularity, applying bug fixes and modifying existing features is difficult and risks introducing new bugs. Testing costs are significantly higher for code that lacks modularity because you have to be extra careful in ensuring that nothing else was broken after an existing feature was modified. Code that is written as a framework allows programmers to easily add new features without having to modify the code that is already in production. On the other hand, if this type of modularity does not exist, adding new features means having to find the place in the existing code base where a new feature can be added, probably having to modify other, basically unrelated methods and classes, and, of course, risking breaking unrelated features. That risk translates into a significantly increased cost in testing and the cost of potentially stopping production.
- Reusability. If there is a focus on decoupling reusable code and placing it into libraries that can be used in other applications, the cost of new development in the future is significantly decreased.
- Performance. Poorly performing code can potentially bring production to a standstill, which translates into a loss of profits. Internal applications that perform poorly result in a loss of productivity amongst employees.
- Security. A security breech can be very expensive. Lawsuits, fines, and a loss of IP are just some of the costs that can be incurred.
Please note that I am not trying to make a philisophical case for these being the only design principles. Rather, I believe these principles are vital when considering the cost of development.
Breakdown
Readability, maintainability/extensibility, and reusability go hand-in-hand. However, performance, security, and the first three principles often clash with each other. In other words, making code more readable, maintainable, extensible, and reusable often results in performance and/or security taking a hit. Making code more secure often results in performance and the first three principles taking a hit. This is why good design is difficult; the developer has to consider every factor and make decisions as to how much security can be sacrificed in lieu of a certain quantity of maintainability, or how much maintainability can be sacrificed for how much performance. A balance has to be struck.
Too many people are hyper focused on a single one of these principles. For example, how often have you seen applications that are so secure that they barely slug along? Sure, they can’t be hacked. But, the security team has accounted for the most improbable events which has resulted in users (let’s say, employees) losing many hours of productive work. In a cost-benefit analysis, was it worth it?
Another example are folks who are hyper focused on performance. Using frameworks that have great paradigms, or building applications with good modularity can reduce costs considerably – often at the cost of performance. Performance, in my opinion, is as important as the first three principles. However, a balance has to be struck here and a cost-benefit analysis has to be conducted in each scenario that requires a programmer to sacrifice performance in lieu of readability, maintainability, and reusability. This requires the programmer to be intimately familiar with all aspects of a computer: from the processor, controllers, and hardware architecture to the operating system, compiler, intermediate language compilation and high level processes, including those of third party frameworks in use. External transmit/receive, messaging, and how third party dependencies process data (ex: SQL Server) also play into this. It is true that performance is probably the hardest part of good design (security is either tied or a close second) because it requires the most knowledge from a developer. That being said, a developer who consistently fails to make smart decisions when choosing between performance and the other four principles is obviously failing to create the most cost efficient code.
SOLID
When you say "design principles" in this day and age, many people tend to think of SOLID, so I had to add a section on it. SOLID, in my opinion, is a set of secondary principles that is used to achieve an end. They are not primary principles because no one ever sets out to achieve any one of these as their primary aim. No one, for example, has ever said "my only aim with this code is to depend on abstractions and not concretions". On the other hand, many folks have said "I want to make this code more readable in order to reduce future onboarding costs". SOLID can also be described as a framework that can assist in achieving the first three principles described above (readability, maintainability/extensibility, reusability).
History
