Going cheap they’re choosing to roll the dice. Maybe they get a good enough product and everything’s rosy. Chances are they get some grade of crap that was slapped together. Provided they had a stable enough product to go to market with they’ll soon understand that maintaining and expanding the functionality of that product is now proving troublesome, slow, and expensive. Now enter the “Agile Elite” to clean up the mess and produce some low hanging fruit. Pull it off and maybe, just maybe they’re convinced that for Green-field mk II project it might be better to try quality over quantity… But pull up the muck boots for some hard yards through the sludge.

My $0.02 of exp.

Long story short I had to dismiss the project for two reasons. It would involve a huge compromise in quality from my current standards and I wouldn’t be able to sleep at night after having completed it. When you know a better road it is hard to take the bumpy one again.

For now I am unable to make that compromise as I’m still learning the ‘agile craft’. I have to use abstractions, patterns and agile testdriven practises exclusively long enough to be able to determine when it is okay to defer from the path. If I compromised now, I would lay awake for days afterwards figuring out improvements of the code. It would be more damaging to my learning curve than any amount of poorly chosen patterns ever could be.

I discussed it with a colleague (who offered the project) and I have to admit – at current I’m not competent enough to take the job – I cannot yet take a poorly written codebase and refactor it enough to be able to fix the problems they have without introducing new bugs. The funny part is that had he asked me 6 months ago, I would have readily accepted the job – contributed to a poor code base with more poor code – and I would have slept soundly at night.

The funny thing is – if you ask me 6 months from now – I might accept the offer, contribute good code to a poorly written codebase just using refactorings. Because there is a hidden business niche here. When you are asked to ‘repair’ an old codebase, you at the same time have the opportunity to introduce ‘low hanging fruit’. Small refactorings that will make the next many ‘repairs’ easier. The customer will see an increasingly stable product and will ask you to fix it the next time.

Customers may not understand code quality, but they can still ‘feel’ software quality when they use it. Every customer has had bad experiences with faulty software. They may stray to other suppliers for a short period of time, but they will eventually return remembering the ‘friction-free period’. It is not always the better businessplan to be the cheapest. Honest business men (and often very succesfull ones) will know how to sell quality. They know that customer loyalty is what will keep them alive in 5-10 years in the future.

If you cannot explain to a customer why they should invest in quality software – you are a poor businessman and thus a poor salesman. It is your fault – not the customer’s. You are the expert – he is (at best) the lay-man.