A few days ago I read Martin Fowler’s blog post titled Is High Quality Software Worth the Cost?. The article talks about balance between software quality and cost. It’s really a must-read for any person involved in process of making software. I highly recommend also other materials from Martin Fowler.
I don’t wanna go into much debate, because I totally agree with observations in Fowler’s article. Thus, I really recommend that you read whole blog post here https://martinfowler.com/articles/is-quality-worth-cost.html. I will just point out some important facts from the article (not in some particular order, but please note exclamation at the end of the statements 😀 ):
- At first glance, internal quality (by Fowler’s definition these are parts not visible to customer, e.g. architecture, design), does not matter to customers!
- Internal quality makes it easier to enhance software!
- Customers do care that new features come quickly!
- High quality software is cheaper to produce!
- Neglecting internal quality leads to rapid build up of cruft (the difference between the current code and how it would ideally be)!
- This cruft slows down feature development!
- Even a great team produces cruft, but by keeping internal quality high, is able to keep it under control!
- High internal quality keeps cruft to a minimum, allowing a team to add features with less effort, time, and cost!
High vs. Low internal quality over time.
Few weeks ago I draw almost the identical curves on one of our company internal meetings. Well, my blue curve was even steeper! :D. The point is, at project start, developers (or PMs) don’t see the benefit of high internal quality (good architecture, following patterns, code styling..). But after a while, benefits of high internal quality starts to show by more progressive development, by shipping features on time, by code flexibility, etc…
I have seen a lot of companies or projects that did not put any attention to internal quality at all. But, while code base and business increased, they started to struggling with more and more difficulties in the code and other processes due to bad internal quality. At the end, you have very strange situation: bad code quality and frustrated folks dealing with this code!
To summarize the Fowler’s post, first, I would like to stress out that I totally agree with him:
High quality software is cheaper to produce!
This sentence combines engineering/technical aspects (quality software) and economical one (cheaper). So, developers should present this aspect to decision makes why it is important to maintain high internal quality even on some “slower output” at project startup.
Although, this statement seems unreasonable, here is explanation (from Fowler’s article):
This is why the question that heads this article misses the point. The “cost” of high internal quality software is negative. The usual trade-off between cost and quality, one that we are used to for most decisions in our life, does not make sense with the internal quality of software. (It does for external quality, such as a carefully crafted user-experience.) Because the relationship between cost and internal quality is an unusual and counter-intuitive relationship, it’s usually hard to absorb. But understanding it is critical to developing software at maximum efficiency.