Code And Cocktails

Delivery vs. Code Quality: Any Corners Safe to Cut?

| Comments

The balancing act between delivering vs. code quality has been on my mind lately. It seems to me that there are times when delivery trumps code quality. But sacrificing code quality for delivery speed results in slower delivery of future features.

(‘Code Quality’ here is defined as ‘good design’, ‘easy to change’, ‘easy to understand’. This is not about quality as in free-of-bugs: that is not a corner I will cut. I am also not suggesting writing shit.)

Are there any corners which are safe to cut? I have a feeling there is no good answer; but is there a right answer?

I suppose as a bottom line the best to do is to keep the corner-cutting explicit and visible to all people involved (that includes non-developers) so that the eventual slowdown will not be a surprise.

Or is this just an invalid assumption on my part? Is there any time that delivery can trump code quality? I know that everyone says that keeping code quality high is the only way to go quickly (@unclebob’s pithy: “The only way to go fast is to go well”). But that seems to be to be about the long term; I am talking about short term speed gains.

This is something I’m going to continue to think about; I’d love to hear your thoughts on this.

Comments