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.