This round of pet peeves is focused on the concept of rework & technical debt. I haven’t done a pet peeves post lately but I didn’t want you to think I’ve lost my critical annoyed mind. I may not be doing much on the technical front these days but the views regarding this aggravate me.
- Just avoid it in the first place: That’s not possible. Tools change. Technology change. People change. Requirements/stories change. Situations change. I really wish technical debt had a different label – debt implies it could have been avoided.
- Bad quality/people: Aside from the fact that you can’t avoid technical debt, the view point that this is a result of bad people or lack of quality is harmful. People are forced to make difficult choices in the moment that shouldn’t be evaluated later with an air of judgement. Tradeoffs are made due to the constraints at the time – everyone is doing the best that they can.
- No value in addressing: One of the frequent challenges, is finding time (prioritizing) working on technical debt. I’ve often made the cost super visible in addressing the debt – new innovations if we updated the architecture, increase of amount of stories completed, etc. Think what’s in it for the product team, business and customers to focus on this work. Too frequently, technical teams are highlighting their challenges and not the benefits of doing the work.
- Has to be done all at once: The best architectures and designs emerge (subset of agile principle). Thinking you are going to perfectly rework something all at once and only once hits on the other pet peeves. As you work on new work, improve old work. Do a little at a time.
As much as these are pet peeves, they are mine and as a leader that doesn’t mean I get to simply judge others. Instead, these serve as opportunities for others and for me to grow. If this stuff was easy, I wouldn’t be sharing.
What are your technical debt pet peeves?
