Average Code and Cost Of Change
time to read 2 min | 262 words

I got a couple of comments on my previous post about code quality and developers quality, where clients demand lower quality code. Basically, "that is the way it is".

I don't argue that this is happening, I had to butt head against to approach before, and I can sort of understand the arguments from the business side. The problem is that the approach is flawed.

I get to see quite a bit of average code (By my standards, average doesn't mean bad). It is usually straightforward code, sometimes it does more than it needs, but in general, it is not a problem to understand what is going on. The problem with average code is that it usually much harder to handle change.

It is hard to change because the code needs to do a lot more than it would have done had it been using a smarter approach. I find that it is much easier to train developers to use better tools and approaches than to lower the level of the code to the level of the programmers. Most developers would like to learn new stuff, not work on the same rusty codebase.

The end result, from the business perspective, is a higher quality product that was delivered faster, costed less, and whose maintainace costs are significantly lower. Of course, this necessitate investing in the developers, and that comes out of the IT budget. The cost of projects comes from someone else's budget.

 

Tweet Share Share 0 comments
Tags: