Quality
That without a name would smell as sweet.
Quote category two in the Desktop Don Reference (DDR) is about Quality. Quality is difficult to define in any concrete way. Whenever I try and define quality, I remind myself of a quote from George Carlin.
Have you ever noticed that their stuff is $h!t, and your $h!t is stuff?
Quality is a subjective measure. We have no common frame of reference for what exactly constitutes quality. But oh my gracious, we do tend to have strong opinions on what constitutes $h!t! We see crap code everywhere. We talk about code in terms of the smells it produces. Odiferous opinionated critics are we. Whiff, Whiff!
And our code? Smells like a brand new car. We all love our used cars. Yeah sure, you bought that car when it was brand spanking new. Guess what, two weeks later… it’s a used car! The new car smell goes away quickly. The only difference between one old car and another is how well the owner takes care of it.
Quality
Quality is not an accolade we achieve in software development. It’s not something with a shiny bow on it that we can put on a shelf. Software changes, adapts, evolves, or is abandoned and eventually dies. Quality is something elusive we have to continually strive for. Quality is defined by the culture of the team that works on the project. Establish and agree as a team what you care about. Establish measures for those things. Automate the measures as much as you can. Don’t leave your software to rot. Understand that the behavior of the humans working on the software will ultimately define the quality of the software.
The following are the three quotes from the Quality category with an explanation for each.
Fix broken windows when you find them.
This quote is directly from the Pragmatic Programmers, Dave Thomas and Andy Hunt. The Pragmatic Programmer book is one of my favorites, and I highly recommend it to all developers. In the section of the book where this tip arrives, there are two stories. One story focuses on the theory of how neighborhoods deteriorate. It usually starts with one broken window. Folks who enter code bases that are already in disarray tend to follow suit and only change the minimal amount to add necessary behavior. A second story is about an immaculate house that has a fire, and the firefighters who go to put out the fire take extensive care not to mess anything up in the house and only focus on extinguishing the fire with as little mess as possible. If you work on an immaculately consistent code base with great attention spent on defining style and substance, you will take your time to make sure you leave the code as clean as you found it when you make a change.
What does it mean to me?
The difference between an immaculate code base and one that is in disarray is the care the people who work on it take. Developers who don’t give a $h!t about the code they create, usually create the most $h!t code. Developers who do give a $h!t tend to clean up the $h!t that developers who couldn’t give a $h!t spread around. These developers are also not afraid to help the developers learn how to make changes without messing up the sanctity of the code temple.
Fix the broken developers when you find them. Spend time with them. Explain how things are done in a code base. Make them feel welcome. Realize that most developers will only ever have worked in crappy code bases where there was no culture of caring. They may have no experience with “what good looks like.” Show them what it can be like if we all pitch in and keep our used car in good condition.
Premature optimization is the root of all evil
A famous quote from Donald Knuth, the author of “The Art of Computer Programmer”. Optimized code can be harder to read. We should only optimize if we can demonstrate there is a significant benefit.
What does it mean to me?
Simplicity is a quality that is hard to achieve. Writing code that is readable and easy to comprehend by current and future generations of developers. When we write optimized code, it is important that we make sure that even the optimized code is comprehensible by current and future generations. Sometimes optimizations are useful for a point in time. If the code is not well understood (different than easy to read) then it may be harder to change or remove later. We should make sure an optimization is well tested and suitably commented so others can validate their own changes in the code don’t break the optimization.
Do things once and only once
A quote I attribute to Kent Beck. Here’s info on Once and Only Once from the C2 Wiki.
I like to poke fun at the DRY principle (Don’t Repeat Yourself) from the Pragmatic Programmer. We should not need principles that duplicate each other. I believe the DRY principle was defended in the book for going further to include everything around a project including documentation, etc. I still think it’s kind of funny, so I decided to stick with Once and Only Once.
What does it mean to me?
Some might think that I have been a bit excessive with this quality in my own software development life. The development of Eclipse Collections is a perfect example of profound dedication to Once and Only Once. I believe addressing duplication across projects is just as important as duplication within a project. We should not limit ourselves to removing duplication in one project, to find ourselves repeating the exact same duplication removal in another project. I have a separate blog dedicated to my feelings about Code Duplication and Once and Only Once.
That’s all for Quality
I hope you enjoyed the read, and will stay tuned for category number three: Process. If you haven’t already, you can read about category number one: Simplicity.
Thanks for reading!
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.
