Root Causes of Technical Debt
- Taking Down the Hubricists
- Talking with the Face in the Mirror
- Risk-Averse Organizational Attitudes
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When we spend 80% of a development budget just keeping software that we already presumably "own" working and current, we know that technical debt is extracting a terrible toll on our budget. When making a simple program change requires effort measured in weeks rather than days, something has gone horribly wrong. In many circles, the term custom software has essentially become synonymous with "blank check" and "will drain your budget for a long, long time."
Do you champion change to help reduce such technical debt? You may eventually be rewarded for your foresight—but meanwhile the risks of championing change are very high. If you want to write maintainable software, a multitude of barriers stand in your way. When you admit that you can't state with absolute certainty what will be delivered, do other people paint that disclosure as an admission that your team lacks discipline? Do your developers who have not yet tried pair programming or test-driven development reject those techniques without ever really attempting them—just because they're new and initially uncomfortable?
Previous articles in this series have explored the problem of technical debt, the ultimate costs of this problem, and how methods that work only at surface levels stifle the possibility of changing to something better. In this article, we'll consider why these problems affect our technology organizations in the first place—how technical risk factors into the technical debt that plagues the software industry.
Taking Down the Hubricists
I defined the term Hubricist in my article "Scrummerfall: World's Worst Software Development Methodology." The Hubricist attempts to impress those above him by replacing real data about the real velocity of the project with hubris. What the Hubricist lacks in substance, he makes up in bravado: "Yes, we will hit the deadline. Yes, you will get all the features!" When neither happens, developers are blamed for not working Sundays in addition to Saturdays, and careers are derailed in the aftermath.
Why is the Hubricist so opposed to change? For a moment, try to think from his point of view. Somebody (perhaps it's you) comes along and trots out this methodology that promises transparency, particularly with regard to quality and technical debt. Is this methodology good for you, Mr. or Ms. Hubricist? Where would you fit into a regime that values results over bravado? Results-oriented management might not allow you to blame other people when things go wrong. If customers see that developers are making progress on a daily basis—working hard, but not at the unrealistic rate of progress you promised in order to sell the project, where does that leave you? Exposed, having made a lot of promises that can't be kept.
With this kind of mindset, it should be no surprise that Hubricists try to block adoption of Agile methodology, or any other system that adds transparency. Remember the scene in The Wizard of Oz where the curtain draws back to expose the little man behind the booming voice? When the Hubricist perceives the potential for exposure, he plays the FUD card: fear, uncertainty, and doubt. He walks around claiming that Agile isn't disciplined, that it's about developers who don't want to write documentation, that it's advocated by teams that don't want to be held accountable for results.
What can you do to counter the Hubricist's claims?
- Point out that Agile teams actually tend to produce far more useful documentation than other methodologies can. These are real showcases that demonstrate working software, versus mere status reports with vague claims of xx% complete, based on nothing but self-reported guesses.
- Note that accountability for results must be based on a solid track record of delivery. Is a high percentage of the development budget spent on software maintenance costs? Past results don't allow you to claim "accountability" for the future unless you have changed those statistics.
- Show a real Agile team. Show stakeholders the daily artifacts of story cards moving from backlog to completion. An Agile team room is an active place, where collaboration tends to be visible and signs of progress are frequent. Compare this to a typical cube farm in a waterfall project.