As I read “Clean Code” by Robert C Martin, I was particular drawn to the passage about why unrealistic commitments should not be an excuse for writing bad code. He points out that while it is a manager’s job to “defend the schedule and requirements”, it is a developer’s “job to defend the code with equal passion.”
What management says vs what management wants
One way this becomes a problem is when a developer hears management say “I want it by Tuesday.” They may want it by Tuesday, but does that mean they are getting it by Tuesday. The manager also wants it to work correctly and meet all the requirements. A manager isn’t going to be happy if we claim it is done on Tuesday and then a whole pile of rework needs to be done afterwards. This really means the task wasn’t done by Tuesday and we just claimed it was.
“Done”
The manager also doesn’t want this one date to be met at the cost of meeting other dates. One way this comes up is by saying the task is done while silently thinking that parts of it will be done “later.” Regardless of whether “later” ever comes about, the task isn’t REALLY done. When I disagree with someone on whether a task is done, I’ll ask if they need anymore time to work on things related to it. This may bring up parts of the task that aren’t really done. Sometimes it brings up additional tasks that were discovered during this task. Either way, it is often a productive answer.
Trust
When unrealistic estimates come up, there are often two responses. One is to silently accept it knowing the date will not be met (or will be met at the cost of other things) because it is “what the manager wants.” The other is to discuss why the estimate will not be met with management. Of course, the later requires much more energy at first. However, it pays off in getting everyone to have a realistic understanding of the project.
Schedule gambling
These other desires tend to be implicit, so we only hear the deadline. That doesn’t mean that the manager wants it done by Tuesday at the expense of all else. I’m fond of saying that management would rather meet the production date than a development date. So if we are meeting the development date at the expense of something that affects the production date, management will really be less happy. This may be sloppiness that makes other tasks take longer or leaving parts of the task incomplete.
What all of these things have in common is that it is our responsibility as developers to keep management up to date and provide them with accurate visibility into what is going on within the project.
—-
This coming week we will be hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum. Come on in, ask him a question or join the discussion. You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.
I was e-mailed a question asking where this was in the book. The part about defending code is at the top of page 6.
sounds good on paper. How about the situation where you’re assigned a problem, then explain to the powers that be- “what about this situation?” and the reply is “don’t worry about that, fix this….” Or, just make it work- we’ll worry about [fill in catastrophic end of world prolly never gonna happen problem here] later? To me bad code isn’t necessarily code that’s broken right out the gate, it’s poorly thought out, cobbled together code that works- for now. Until the poor mensch assigned to modify this stuff has to deal with it.
Boose,
I wrote this thinking about the scenario of regular development where the code/feature is being initially implemented. If management is going to say they want crap, it’s our job to work with them to understand why they really don’t. And when going through the long term consequence does often help.
In terms of the “emergency” fix, I’m more flexible. Depending on what it is. I’m still likely to push to make sure they know exactly what the risk is. If it’s messy code that “works” and will “just” be a maintenance issue, we can clean it up after. So long as it gets added as an actual action item on the list – that way it gets done. If it’s compromising something that will hit us this time, we tend to talk more about it. Whether that’s getting the business user’s agreement that “atastrophic end of world prolly never gonna happen problem here” is ok or the like.
Pingback: why do i blog? | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky