Like the spat between Uncle Bob and Joe Spolsky, there are many misconceptions when it comes to talking about the trade-off between code quality and development speed. For some reason, the code quality people think that the other group is a bunch of caffeine-spiked, low-IQ programmers who are just good at typewriting.
Consider this statement from Ron Jeffries:
Suppose you are in the middle of putting a feature into some code and the code needs improvement. Suppose you have noticed a variable name “joe” that should really be given a meaningful name like “personBeingHired”. It will clearly take more than zero time to do that renaming. Therefore, trying to improve the code will slow you down.
Well, maybe. But if you’ll walk just a little faster to the coffee room next time, you can make that time up and it’ll do wonders for your heart as well. The slowdown from simple improvements can be quite trivial, quite capable of being absorbed in the natural flow of things, without any real impact on delivery at all. And that’s this time.
Next time you pass through this code, all that thinking you had to do to figure out what the hell “joe” meant can be saved. “personBeingHired” makes sense. Your understanding will come faster, and the feature will go in sooner.
This effect might even hit you on the first time through. Is the code a bit intricate? Then improving the variable names can help you understand it this time, and help you avoid errors as you make your changes this time.
The key assumption that Ron makes is that the people who talk about development speed are fond of making simple mistakes like using a variable name like “joe”, or that they are not familiar with development environments like Eclipse or Visual Studio that can allow you to make that refactoring with a single IDE command.
And here is Robert Martin again, psychoanalyzing programmers:
These people have surrendered to the drug of speed. They need to conquer. They manufactured their own deadline pressure and behaved as if their boss was breathing down their necks.
How do you really get things done quickly? You listen to your grandparents. Remember what they told you? “Slow and steady wins the race.” and “Anything worth doing is worth doing well.” How does a professional craftsman get things done quickly? He/she adopts an attitude of calm, focuses on the problem to be solved, and then step by step solves that problem without rushing, without yielding to the need for speed, without surrendering to the desire for a quick conquest.
Ron and Bob’s mistake is that they bracket incompetent programmers with highly capable programmers while talking about development speed. The former make fundamental mistakes like formatting, naming of methods and variables, and basic logic, and do not have the skills, intelligence or other factors to write good code. However, there are very good developers who write excellent code with few bugs at the first try. When they grouch about quality, they are usually talking about design-level coding principles, where there is usually a lot of debate.
For example, no one disagrees that you need to write unit tests. But people disagree on how much code coverage you need. No one disagrees that you have to design your classes or database tables properly. But people disagree on specific principles when it comes to class or database design. No one has a “low quality” business strategy and is purposely intent on producing low quality code. But people disagree on the level of quality required in code.
Good quality is not an absolute measure. There is always room for improvement. There are always things you can do to make the code even more streamlined. So there is a point where you have to say, “This is good enough. Let’s ship.” You have the liberty to define what “good enough” means, and your customers will tell you (in one way or another) whether your judgment was right or wrong. Sometimes, these decisions have to be made at the start of the project, so that you know how much time you will spend coding for the first release.
And make no mistake: Quality has costs. And extremely high quality has extremely high costs. Let’s count: Experienced programmers in the entire team (no newbies), code reviews, full testing coverage at unit test level and acceptance testing, user experience testing, more documentation, management costs. Joe Rainsberger explains (with a slightly confusing post and graph) that while low quality can slow you down, at some point, the reverse is true: high quality will slow you down, because the additional quality does not save you the equivalent amount of time.
Another mistake often made by people like Ron is that they assume that longer time and higher costs for the entire project is unacceptable. This is not necessarily true. For example, if a company rolls out a product faster, they may gain more customers, gaining revenue to fund more development. If the company has competent programmers, the code is acceptable enough not to bury it under a cycle of bug-fixing, and they will have money to hire more programmers for the team.
The ability to ignore known bugs and roll out the application can be very important in the face of competition. If your competitor rolls out an imperfect product and gains a lot of influential customers while you wait for another month to release yours, you may go out of business. The last straw will be that the competitor releases the important patches to their product at the same time of your first release, because their customers helped prioritize the bug list.
A last word on this (which I had left as a comment on Martin’s blog and will expand upon in a future post): This debate has something to do with software product development in smaller companies. In software product development, the upside of delivering early is huge because of the marketing advantages. With more money, you can go back and correct mistakes you have made in the past. Obviously, the code shouldn’t be a total wreck, but here we are talking about startups, whose founders and principals will be good programmers.
In internal projects or work on mature software products, releasing frequently is not necessary and has to be done carefully to avoid breaking something that works for existing users. So there is a bias towards quality improvement. The problem is that many companies get this miserably wrong, as they keep piling on process after process, standard after standard. In fact, the Agile movement (to which Ron & Bob belong) was a response to such overblown software methodologies. But apparently, they are again advocating a similar dogmatic approach to code quality. The more things change, the more they remain the same.
[Photos licensed from migs212 and licensed from nikrowell]