Photo by Lubo Minar on Unsplash
Uh, oh, that dead code again.
Much of the time we let the managers know that there's a lot of technical debt in the code: untested code, leaky abstractions, sometimes even variables named a, b and c. We need to set up a CI and a linter. But when?
In this post, you'll see why you should care about taking technical decisions, and why you need to start participating, proposing, and/or proactively make them along with your team.
I always thought that these depended on management!
Software is meant to help people accomplish their goal. Also turns out, Managers are the ones that know what needs to be done from a business perspective to accomplish the goals. Therefore, it makes sense that they should decide when it would be a good time to tackle the technical debt?
When I initially reached this conclusion, I abandoned refactor. I abandoned tests and radicalized my point of view about business having the final say on every technical decision. Blogs like these became my mantra: Your code may be elegant, but mine f***ing works.
Turns out, you also know what needs to be done
A year ago, I stumbled across this passage from Clean Architecture, by Uncle Bob:
Fight for the Architecture.
“Fulfilling this responsibility means wading into a fight—or perhaps a better word is “struggle.” Frankly, that’s always the way these things are done. The development team has to struggle for what they believe to be best for the company, and so do the management team, and the marketing team, and the sales team, and the operations team. It’s always a struggle.”
The passage opened a crack on my beliefs. Why should we fight with the people that know what needs to be done? Shouldn't the managers be the one factoring out all the constraints, including technical debt? Turns out most of the times these constraints are overlooked - indeed, only the people experiencing the problem knows that the problem exists.
Most of the bigger goals depends on smaller goals to be achieved. It's the work of the doers - people like you, who make things happen. Who else knows best what you need to do in order to accomplish your tasks?
You are responsible for the success of the product -- and your work
When unexpected things happen - be it breaking a fragile piece of code, or failing to meet a previously agreed deadline - who's to be blamed? Turns out you're the one responsible for estimating your tasks and working on it within the constraints. Unexpected things often occur of a lack of quality in the work that you're expected to flawlessly do.
If you estimate a task to be completed in 3 hours, but it ends up taking 8 hours - because by doing it you broke something else and had to spent 5 hours tracing and fixing the issues - YOU will be responsible of it!
To ensure quality in your work - that is, to meet the requirements within the given constraints while avoiding unexpected issues, you need to impose certain quality requirements to the work that you do. Does it require tests? Does it require to pass a linter? These tasks don't necessarily deliver a feature to your customers, but helps you to do so!
Wrapping up
You, who work on the code on a daily basis, know best what kind of problems you're dealing with. To solve these problems, you must take actions. If you don't and instead rely on your product owner or another authoritative person to, they might not see the problem until it becomes too late. When things start to crumble and you're unable to meet your estimations - the fault with be on you.
Because you want to do the best out of your work and hold it to high-quality standards, you need to proactively take actions to combat the technical debt. Doing this is part of your work.
References
Apart from the linked content, this article helped me a lot to articulate my ideas around the topic: The programmer as decision maker.
Top comments (0)