Code Quality versus Development Speed

by Krishna on February 3, 2009

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.

code quality

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.

code

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]

{ 7 comments }

Abhilash February 4, 2009 at 12:58 pm

>> Experienced programmers in the entire team (no newbies)

I take exception to this statement, although the statement about the cost of quality is largely true. Experience doesn't always mean quality and newbies doesn't always mean low quality.

Krish February 4, 2009 at 1:09 pm

You are right, Abhilash. It should probably be “verifiably talented programmers” instead of just “experienced”.

J. B. Rainsberger February 7, 2009 at 11:26 am

I realize that I did not express myself well enough in the article, so I will post a revision in the next few days clarifying and refining what I meant. I hope you’ll read it.

Krish February 7, 2009 at 4:53 pm

Definitely, Joe. I will look forward to reading the updated article.

Anonymous March 14, 2009 at 2:42 pm

>>>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.

BS. You're telling me that "good" developers don't need adequate time to "think" about what they are doing? You don't think that testing is important? You don't think that every developer has their struggles in code?

Common man. It's common sense. You're the typical dude who thinks his shit does not stink and therefore your code doesn't ever smell and so you can "go as fast as you can" saying that slowing the business down to work in realistic deadlines is something you should not fight for.

Dude, get into reality. This is not an argument about good or poor developers. This is about having a SANE and process oriented (Agile if that's your cup of tea or even not..I don't care what you use) environment where quality is at the forefront, not speed. Speed is a direct results of quality. Talking about who's good and who's not on the team is relative and the way you presented this post tells me you never have to slow down to work on logic, figure something out, or that your code has a lot # of bugs. How do you know this? Because YOU tested it and said it's sufficient? Did you unit test it? Did QA test it? I call your BS. So go ahead, hack up another solution for your company. Later on we will be fixing your shit down the line whether you think your shit stinks or not because you feel rushign to product a product (whether that be not just code but a car, tv, airplaine) is justified becuase you're a "better coder" than most. Fuck that. Give me a break. That's a lame argument.

Anonymous March 14, 2009 at 2:45 pm

>>>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.

Dude you are a total idiot. Because we made it fast to market, we can spend 10x more fixing it later.

I am glad you are NOT on my team.

Krish March 14, 2009 at 6:49 pm

@anonymous, reading your comments, I wondered whether I had written a different post because you seem to be putting words in my mouth. Please read the entire post so that you understand the full context of what I am saying. You will find you have constructed a strawman argument.

As I mentioned in the post,

* Nothing in my post says anything about not testing. Here is what I wrote: “no one disagrees that you need to write unit tests. But people disagree on how much code coverage you need.”

* Nothing in my post says anything about not slowing down to work on logic. Here is what I wrote: “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.”

* You need competent programmers to do the work so that you produce reasonably good code. If anyone including me creates code that creates a lot of bugs, that means that they are not competent and probably should be fired before they can do more damage. You should not be hiring such people in the first place.

* Read my link to Joe Rainsberger. Too little quality reduces your speed because you have to keep fixing bugs. Too much emphasis quality also reduces your speed because you get mired in bureaucracy.

* The definition of “enough quality” depends on your situation. And how you achieve it depends on the processes you have in place. I totally agree with you that this means a “sane and process oriented environment”.

* The quality vs. speed equation works differently for startups than established companies. Again, I am talking about competent programmers and “sane” development practices (including code reviews, testing, etc.) If you have that, you don’t need 10x time fixing any bugs later.

* My post is NOT written from the perspective of a developer working in a team and deciding what to do, and others having to fix the problems. It is written from the perspective of founders who have to live with the consequences. Founders who are competent, experienced programmers and able to crank out good code.

Finally, from a human being to another,

* Stop calling names and learn to disagree without being disagreeable.
* Don’t assume something about others by simply reading one post. By suggesting that I am some sort of programmer, it is clear you don’t know what I do at work.
* Instead of being anonymous, why don’t you try debating this in the open if you are truly interested in having an thoughtful conversation that helps everyone?

Comments on this entry are closed.

{ 1 trackback }

Previous post:

Next post: