What is a developer's responsibility when a customer asks for a quick and dirty solution? Should they listen to the customer and take the short cut because, after all, they are paying the bill? Should they instead always do what is technically the "best" option in their opinion? Or is there a middle road that should be taken?
James Shore in Our Professional Responsibility gives a brief history of the customer/developer balance:
In the bad old days of waterfall development, programmers would figure out requirements, create a design, and then implement the design in the way that was most technically convenient. Programmers were king. Plans were created entirely by programmers. Or the programmers' Big Boss set a deadline--perhaps motivated by political pressures, or by romanticized memories of what he could program over a Jolt-fueled weekend--and programmers scrambled to meet it.*
*Yes, I'm over-simplifying a complex situation. I'm Allowed.
Agile development reacted to this, saying, "Hey! Wait a second! This isn't working! We're not delivering value to our customers." The planning game restores balance to the equation. Customers are in charge of value; programmers are in charge of cost.
Some agile teams have let the pendulum swing too far. They've abdicated responsibility. They say, "The customers are in charge! We have to do whatever they say."
That's taking it too far.
In his opinion, developers should not be in charge, but at the same time, it is their responsibility to develop quality code. Always.
And when someone says, "Can't you take a shortcut and get this done faster?" look them straight in the eye and say "No." "No, we can't do that without hurting our schedule. But I can help you find ways to simplify features so we can finish faster."
Reg Braithwaite, in What I admire about professions like Engineering and Medicine, suggests that it may not be a bad idea to listen to the customer if they want a quick and dirty solution in some cases:
Now, I don’t agree that you should refuse to slap together quick and dirty code that will be hell to maintain when told to do so. Whether that is a good idea or not is a judgment call. I choose to write software as cleanly as I know how within the constraints of my relationship with my client or employer. I choose to evangelize my judgment on the matter strongly.
But I don’t think I have the right to out-and-out refuse to do so when my employer or client insists. They suffer the consequences of software that is difficult to maintain, so they and they alone have the last word on the subject.
Where he draws the line is not quality, but ethics.
In the case of software development, if I am asked to develop software that is insecure and places private user data at risk, I will make the personal choice of saying no.
Of course, I do not have the protection of the law. If I am fired for doing so, I have no recourse. I can’t even collect unemployment benefits, I will be deemed to have been dismissed for cause. Programmers work at will, which means that you must value your ethics very highly if you are to place your livelihood on the line for it.
Robert Martin (Uncle Bob), in Business software is Messy and Ugly, suggests that quick and dirty solutions are the wrong decision. In response to quote from one of his client's managers "Business software is messy and ugly":
No, it’s not! The rules can be complicated, arbitrary, and ad-hoc; but the code does not need to be messy and ugly. Indeed, the more arbitrary, complex, and ad-hoc the business rules are, the cleaner the code needs to be. You cannot manage the mess of the rules if they are contained by another mess! The only way to get a handle on the messy rules is to express them in the cleanest and clearest code you can.
Finally, in a previous InfoQ article, Refactoring is a Necessary Waste, many of the user comments revolved on when to put time into refactor code and when you should not do so.
So, what are your thoughts on the true responsibility of a developer? Should they "just say no" when it comes to shortcuts? Should they listen to the customer requests? Or, should they be flexible but hone in things that affect the customer and hold fast to their values and ethics?