It created some debate a while ago when Jeff and Joel announced on Stack Overflow #38 that “Quality doesn’t matter that much”. Jeff and Joel had some reasonable arguments regarding for example obtaining 100% unit test coverage and so, but to put it short I don’t agree at all in their main statement, I think quality does matter a lot. But what I don’t think matters are how you obtain that quality.

If you ask me what is the goal I’m trying to achieve when I’m developing software then I will in the very shortest form answer:  To deliver high quality software that gives great value to its users (looking aside that earning money is of course not that bad either). This maybe sounds like a overused sales pitch, but never the less I find great truth in this simple definition of the goal that I believe most of us is actually aiming for. The value to the users is actually the most important part of the goal if you ask me, despite that I believe that quality matters a lot, because high quality software that doesn’t deliver value to the users at all will probably fail anyway,  just for other than technical reasons. Never the less it’s the quality part I’m reflecting on in this posting and even more specific it’s the code quality.

Quality factors immediately visible to the users are always the easiest to understand and in my experience also the ones that the customers of new software solutions are best at remembering to include in their requirement specifications etc.  Non-functional requirements regarding usability, security, performance, scalability etc. are almost always included but that is definitely not always the case when it comes to non-functional requirements like for example the ability to easily change or extend the software solution to support new business needs or to change it to support integration with other standard software (DBMS, Office Suite etc.). Maybe the customer believes they will never need to change the solution in the future, maybe they believe that the code quality has no effect on the ability to change or extend or maybe they simply do not know how to verify if the solution conforms to a requirement like that anyway. However if you ask the customer, “Does it matter to you how easily/cheap/fast you can react to new or changed business demands?” most of them will answer that of course it matters, and especially the ones who have actually experienced the pain of owning a solution for which all changes take long time, cost lot of money and often end up introducing unexpected bugs in part of the solution that was not even suppose to be affected by the change.

But it’s still not always easy to explain to the customer exactly how they need to deal with this requirement. Have any of you ever been confronted with the statement “But we will make sure that the solution can be easily maintained by demanding good documentation”?  I have heard or seen that quite some times and I have often wondered who did start the rumor that good documentation can make up for issues with quality of the code. I have never met a developer who said “I was going to make some changes to this code that I had not seen before and the code quality was not good, there was lot of duplication, the naming was bad and inconsistent, there was no separation of concerns, methods were long and complex, no unit tests etc. …..but because of the good documentation it was still easy to make the changes”.  So I truly believe that the only way to make sure that you can easily change or extend your software solution is to make sure that the quality of the code is high. So quality does matters, because it actually indirectly addresses requirements from the customer/users, they just don’t always know it themselves.

Recently when I saw yet another debate regarding the subject of when to use DDD and when not to, I came to think about how many people, including myself, sometimes almost forget that all of these different principles, patterns and design approaches we use when we develop software, they are not in themselves goals. Using DDD, TDD, SOLID principles, CQS, SOA, etc. when we design and develop software is not a goal in itself, these are just “tools” we can apply in order to reach our goal. For experienced software developers this surely does not come as a surprise, but sometimes it’s important to remind ourselves and especially when we try to pass on knowledge about these “tools” to less experienced developers.

So our goal, the high quality, is not the same as applying all the principles, patterns and design approaches available in every place possible. In some situations less is enough and more just ads to the complexity and in other situations more is necessary. In some situations one design pattern or approach is better than another and in other situations the other way around. And in most situations there are different approaches that give you the exact same benefits in regards to quality. Therefore I also believe that being able to recognize poor code quality is one of the most important qualities of a good software developer and far more important than knowing all the different principles, patterns and design approaches that can be used to avoid the poor quality.  If you are able to recognize that the quality of your code is low or at least not high enough, and you do care to fix that, then you will automatically start to seek information and try out different solutions that can help you make the quality of your code better, and that will make you learn the value of different principles, patterns and design approaches in a proper way, as an reaction to the wish for better quality.

Some might argue that being able to recognize poor quality and being able to fix it is just two sides of the same knowledge. It might be true in some rare cases, but in most I actually believe it’s not, because in most situations there is more than one approach to obtain good quality. Take for example DDD (Domain-Driven Design), a term invented by Eric Evans in his book with the same title.  DDD is an approach to how you effectively use domain modeling in your development process in order to deal with the complexity in software.  But does this mean that DDD as described by Evans is the only way to effectively work with domain modeling or to deal with complexity? No, there are definitely other approaches or variations of the DDD approach that can work fine too, and sometimes it’s enough to use just a subset of the different practices in DDD. It’s important to understand that what I’m saying here is in no way that DDD as described by Eric Evans is not a good approach; I’m just saying that it’s not the only approach that could bring you to the same goal. And DDD is just an example, the same goes for most of the other design patterns and approaches in software development.

This brings me back to importance of being able to recognize poor quality. I have met developers, who tried to apply certain patterns or design approaches but did not really understand why they did it; they had just read that it was a good idea. The result was often not that good.  First of all not being able to recognize what they were actually trying to fix, they sometimes ended up with an implementation that did not really fix the problem or even worse also introduced new problems, and secondly they also sometimes tried to apply a design pattern or approach to fix a problem that was not even present in their particular situation, simply because they assumed that they should just use that particular approach in all situations.  On the other hand, developers who can recognize poor quality will not only be able to see when to use a particular design pattern or approach but will also be able to choose the best implementation. If we take DDD as an example again, then Eric Evans has quite certainly further evolved his approach to DDD since he wrote the famous book 5-6 years ago and so has many other people, and that is because they understand why and when to follow this approach and not only how to follow it.

This is important because as I started saying then sometimes I see people that tend to focus on the ‘how’ to an extent where the principle, pattern or design approached suddenly becomes a goal in itself, which it’s really not. For example I have seen the question “How should I implement repositories?” many times, often with a reference to that Eric Evans is not really showing a full implementation in his DDD book. However I actually think that the most important part about repositories in the book is when Evans lists and tells about the advantages of using a repository pattern, because these advantages are really the guidelines for your implementation. If you have made an implementation and you can see that you have obtained the advantaged described in the book, and you cannot find any other code smells, well then you have definitely found a good implementation of a repository that suit your needs. It doesn’t necessary look like implementations that others have come up with, but that is not important as long as you obtain the advantages.  The advantages are the important part, not if you obtain them in one or another way.

So if you are developer who would like to become better at developing high quality software my advice is to make sure you know the whys (reason for choosing a given design pattern or approach) very well, because that is really what is going to help you choose the most appropriate how (implementation) in your particular situation.  And when thinking about the whys then do remember to follow the link all the way back to the requirements of the customer/users.  For example there are different design patterns and approaches that help us avoid code duplication but actually then “to avoid code duplication” is not the real reason for us to choose a certain pattern or approach, because code duplication is really not a problem if the code will never change. So actually it’s the requirement of being able to easily change or extend our software solution to support new business demands that is the real reason and avoiding code duplication is then just a principle that has emerged because of some logic/experience we have applied to that non-functional business requirement. We need to be able to easily change or extend the software solution to support new business demands (business requirement) + It’s easier to change code when it should only be changed in one place rather than in many places (logic) = We should avoid code duplication (principle)

So with this in mind is does not matter which design pattern or approach you choose in order to avoid code duplication what matters is that you avoid it, and you will find that in some projects one approach suits your needs and avoid the code duplication and in other projects you maybe need another approach. A good example, however not only related to avoiding code duplication, is the whole debate of whether a Transaction Script or Domain Model pattern should be used for structuring your business logic and also how a Transaction Script / Domain Model implementation actually looks like. My best advice would be to chose the simplest (because simplicity is also a factor when talking high quality) approach that conforms to all of the principles you have derived from the business requirements in your project. It doesn’t matter if that approach and implementation you choose is closest to a Transaction Script or Domain Model design pattern, what matter is that it suits your needs of delivering high quality in that particular project.

The described mindset, and way of approaching on one side the wish for higher and higher quality and on the other side the many principles, patterns and design approaches available, have helped me when making design decisions affecting quality and also helped me finding ways to better explain the necessity of high quality to those who at first believe it's not a concern of the business to care about code quality. Maybe some of my reflections can help you too.