2/16/2009
In his recent post - Quality-Speed Tradeoff — You’re kidding yourself, Ron Jeffries has explained how high quality is mandatory in order to achieve high delivery rate.
There are many reasons for quality issues in a product, inherent technical complexity, lack of skill or just plain laziness. However an over looked factor that really hurt quality is pure pressure. When the pressure to deliver rises above a certain level (which vary for people and teams) the team starting to cut corners. When pressed developers will deliver. However we are not magic workers. When pressed we usually starts by working longer and harder, but when that's not enough, the only option left is to compromise current quality in the hope that part of the work can be delayed after the delivery. The mistake involved is the belief that after the release there will be time to fill in the blanks so to speak. naturally there is never enough time. In the agile community we even given those cut corners a glorified name, we call the work we should have done "Technical Debt".
Bad Quality is Infectious
The real problem is that bad quality is infectious by nature. It can starts by maybe skipping a needed refactoring, it might start by not writing unit tests for a given component (assuming we will do it later) but very soon islands of low quality code start to form. As time goes by these islands have a tendency to grow. In a large enough code base they hide themselves for quite some time. They are always discovered at an inconvenient time when they affect work being done but when there is no time to actually fix it, so another workaround is coded, and again quality suffers just a little more. So they grow and grow until bigger problems starts to show, suddenly the escaped defect rate has significantly increased, adding new features become harder and takes longer. And quality continues to deteriorate until something is decided to be done about it. The problem is that by the time we reach the this stage the cost for fixing the issue is high.
Good quality is also infectious
The good news are that good quality is also infectious, most programmers (at least those I know) really want to do a good job and achieve a high quality code. So it doesn't take much effort to keep us on the high quality road. I have seen cases that a single team member by not compromising quality, cause the rest of the team to follow, even at points when pressure was high.
So the morale of the story is very simple, quality for me is mainly a state of mind. The moment I accepted the fact that by trading quality I always but always LOSE (and constantly reminding myself of this) I find it easier to achieve better quality. The up side is that I saw how this kind of approach infects others as well.
Posted in: 
Posts
4 comments:
I couldn't agree more. Bad code is a really slippery slope. One of the worst things about bad code is that it sets the bar for the quality of the codebase. Another programmer may come along and write some equally bad code, citing the initial code as a reason why it's ok to do that.
How do you go from bad code to good code though? That seems like a tough problem. There's no overnight fix that's for sure.
Often it will require a monumental effort, with little improvement as seen by those on the outside, so it's a really tough sell. We can't really measure how much we're slowed down by this code, so it's hard to explain the payoff for fixing it to management types.
As I mention in the post I think that the first step is actually admitting the problem and stop injecting more bad quality.
only then we can start talking about improving.
Hi Lior,
Cool blog, I like it!
You said you can volunteer in http://code.google.com/p/mocking-frameworks-compare/ development :)
At the moment, I'm thinking of a suite for testing MVC - the one that would cover some basic MVC testing scenarios (as usual, for Isolator/NMock2/Moq/Rhino).
Would you like to start that part?
Cheers,
Andrew
Hi Andrew,
thank you,
Lets take it offline, can you mail me on lfriedmal at gmail?
Post a Comment