Why Your Manager Doesn’t Like To Throw Away Work (And You Do)
Filed Under Human Factors
Awhile back, I read two very good blog posts both talking about technical debt and passionately treating it as a sunken cost. The 1-2 punch of these articles made me much more aware of the long term effects that “rotten” software can cause.
The majority of the time it is management that has a tough time throwing away previous investments. Hypothesizing, I believe this is for two reasons:
1. Lack of visibility
Because managers are not doing the work they do not have the visibility of how evolutionary the current project may or may not be. Some projects move and shake a lot, others are more linear in nature. Although requirements may evolve (or even contradict), progress will often give management the illusion of being linear.
2. Fear of promoting refactorbation
In the majority of cases, it is not the developer who is afraid to throw software away. I have seen developers literally beg that previous work be tossed out (and in most cases the work is even their own). It is my belief that developers actually represent the unhealthy reciprocal of this situation by refactorbating.
Managers do not want to fuel a need to code towards unattainable perfection, thus sacrificing velocity towards the end goal; after all nobody but the developer cares what the code looks like.
The manager can always reject a request to refactor, likewise, the developer can pull the trump card and never ask for permission. So what can both sides do to defend against each other? Previously, I have struggled with a number of ideas, but have boiled it down to these tips, one for each side.
Developers – Pick your battles
Learning not to cry wolf every 5 minutes is important. If asking permission for a large refactor is an exception rather than the expectation, the validity of your request will be weighted heavier.
Which battles do you choose to fight? Pick the battles that will cause you long term maintenance headaches. Wanting to refactor 50k lines of code to use generic collections rather than typed collections? Probably won’t matter in 5 years, generics will be out of date too. Want to refactor Crystal Reports out to use SQL Reporting Services…now that is probably a good refactor…
Managers – Maturity + Trust = Permission
Again the responsibility/authority principle comes into play – you can’t give one without the other.
If you have a mature developer coming to you, and you trust them to act in the best interest of the project, their should be no reason you never deny them the authority to execute – get the hell out of the way.
If you trust the developer, but they do not have the maturity – find a lead developer to make the call.
If you have a mature developer that you don’t trust – fire them. There is no room in business to be working with people you don’t trust. Period.
Throwing away work is not a crime, but carrying technical debt is. Learn the difference, and sometimes time lost is actually time saved.
3 Responses to “Why Your Manager Doesn’t Like To Throw Away Work (And You Do)”
I think your issue about developers learning to pick their battles is well thought out. Many developers have unfortunately isolated themselves from what drives people’s decision making process. Many times their desire to refactor have the worst timing.
I had a very talented developer fall into the chronic “we’ll make it extensible and it will save us money” syndrome, and nearly kill a project because all the easy things that the customer wanted to see early were eschewed because it was not important for the future. Had the customer seen a few screens and some of their process modeled quickly, they would have gotten on board with the other ideas that the developer wanted to pursue. His ideas were well worth, but his timing and ability to see what was important to the person paying the bills was way out of whack.
I have some similar posts concerning this issue:
http://activeengine.wordpress.com/2007/11/21/clarity-of-thought-only-comes-from-practice/
http://activeengine.wordpress.com/2008/01/10/the-art-of-letting-bad-things-happen/
Nice post, Max. For me it’s always been #1, lack of visibility that is the most problematic. I used to work for a university where my manager knew more about corn than he did software (it was an Ag campus). It was quite frustrating, especially when he was the one making software decisions. That was one of the main reasons I quit 🙂
I guess that kinds of ties in with your last paragraph: Managers-Trust-Visibility+Ego = No Employees
Lack of Trust = Micro-management = Ineffective.