InfoQ summarizes a couple of blog entries discussing what responsibility we have as good developers when the customer asks you to take a shortut. They’ve put the word agile in there too, but regardless of agile or not this is important issues. In short there are two views:
- Say no. You can’t allow anyone to do that, you know there will be bad consequences.
- Say yes. It’s the customer that will have to maintain the ugly code, and he is paying, so let him have what he wants.
I know it’s not easy saying no. Not a lot of developers can afford to start a big argument with their customer, so we all often just do it. But this is always wrong.
The problem with saying yes and it’s argument is the perspective. The perspective outlined in the argument suggests that maintenance of the ugly code will come somewhere in the distant future. This is wrong, the crappy code you write today will hurt you tomorrow!
As you work on a task doing an implementation that is crappy, you will touch code that has been created for another feature, and the feature you will be implementing tomorrow will touch the crappy code you wrote today. And this isn’t a agile weakness, I don’t care how much detailed up front design you’ve done. This will always be true.
So if you let the customer have his way, you’d better make it real clear that this will start to hurt the project from the moment it is implemented. And it will continue to hurt the project until it is fixed.
For the full article click here.
Update: Ferris has a common story of bad code that has a happier ending than most.