Reading Technical Debt 101 inspired me to write my own piece on the subject. I'm trying to analyze what causes it, why does it live on and how to prevent it as the aforementioned article doesn't address the root causes.
If you don't know what technical debt is, and don't want to read the long Technical Debt 101 article, it can be shortly summed up as inadequate technical choices that incur maintenance costs. If you hate making changes in your code, then you have it. If changes are hard to make, then you have it. Living with technical debt is like living with a hole in your roof - you clean up the rain water the first couple times but in the long run you want to fix the damn hole.
There are so many ways to describe technical debt and argue about what's good and bad debt, but the subject here is just the causes of bad debt.
Fear *
Most people assume technical debt is there because of time constraints. Technical debt is sometimes added because of time constraints and it's kept around because of fear. Fear of contesting the worthiness of said time constraints. Fear of change. Fear of refactor. Fear of risks. Management fear risks. Juniors fear getting in intractable situations or just don't know how to solve it better. Seniors with cozy positions fear embarrassment - it's already cozy enough and the golden shackles are so shiny. Why risk looking like a fool and give management reasons for downgrade or lose that minuscule 1% salary upgrade.
But you, yes you, you can take it in your own hands. Fight for change or you'll remain miserable and deal with "legacy" code forever. How to convince management to change and fix the damn debt? Depends on the situation, but it's mostly a matter of ruthless politics. Make campaigns, invent reasons, gather support. Have in mind your reasons are not always the reasons you can sell the management on.
Sometimes it's just too hard to win the battle but you can always pick a different battlefield. Don't fear to admit defeat. It's always better to go somewhere else than getting depressed, demotivated or disgruntled. No one likes to promote demotivated or disgruntled people, you're sticking around in the slum for no gain. Start fresh, and keep the passion burning. In the long run it will be better for your career.
Arrogance *
On the other side of the trench there's arrogance. Managers and people with decision power frequently get arrogant - they think they know it all. Know-it-alls, the worst managers and architects. They take decisions for you but they leave the grunt work to the team. They disregard requests for doing it proper from the underlings. Good technical leaders will listen to their developers. Even juniors can have good ideas.
If you can't leave, for other reasons, then detachment is key. The secret about how to get there is reasonable expectations. If you expect something unattainable from your employer or customer then it's hard to play it cool as you're always in the midst of disappointment. Opposition becomes frustration instead of a simple challenge to explain and convince. Refusals become tragedies. Depending on who you're working with, unreasonable expectations could be expectations of raises, due credit or specific technologies. If those are deal-breakers for you, bring them up before signing up. If it's too late for that then you have two options: the single-use trick - ask for what you want, but if you're denied, you must leave. Not because you need to prove a point, but because it's a good predictor of future denials. This also means it's ideal to have options, you can't bluff. You might even get to keep your current job and do what you want - because you can use the options as leverage.
The other way is to have low expectations. But then you need to find something else to get a sense of accomplishment: focus on the small things, the details - it usually helps. I sometimes call this "the right wrong way to do it" - perfecting something pointless and ugly can make it elegant (and fulfilling).
Have in mind that adapting your expectations is merely a survival strategy, not a career goal on it's own.
Hubris *
Hubris is another problem: you usually see it in the form of over-engineering. Over-engineering is still bad debt as it creates maintenance overhead. It's best to design for what's required now and then have the courage to change and re-engineer. This is known as the "you ain't gonna need it" principle. If requirements change why shouldn't design and architecture change? There's always exceptions but few people have the fortune of frozen requirements and the gift of foresight. Complex systems make foresight difficult as you cannot have everything in your head. You think it's enough to know the programming language - but what about the language's implementation. What about the hardware? What about the external services you're going to use? Simpler architectures or designs are simpler to implement and predict.
One would think you need to balance fear against hubris but this is false. You can start flawed and then you can improve. No manager wants mindless workers. Find the reasons to remove debt, whatever they are. In the end it will be more appreciated than just executing bad orders. Of course, I might be wrong, but then you're in the wrong place. If you're just executing bad orders then either you or your employer is not worthy of your senior-ship. Every time you crumble under pressure to do crappy stuff you're worth a little less - leave, before they treat you like a construction worker. A senior treated like a junior - depression and burnout is inevitable.
On the other hand, you do need to balance hubris against your goals. Goals like "I want to use technology X" usually get you in a dicey predicament. Use it and risk damaging your reputation or don't use it, but loose out on employment opportunities demanding experience with "X". There's no right answer but one thing is certain: "X", "Y" and "Z" come and go all the time. Don't take fashion trends as goals.
All things being said, it's easy to overlook the human aspect of having bad debt. Working with broken stuff is frustrating. It's not enough to put time in the balance, you also need to think about quality of life. You're not paying ahead for saving time, you're paying for happiness. In other words, cheap doesn't necessarily mean good.
Does this sound depressing? Inspiring? Unrealistic? Comment [*] below!
| [*] | More comments on Reddit and HackerNews. |