One of the most challenging parts of working on a proof of concept or alpha revision of a solution is judging when to stop hurdling forward and revisit and judge your own work. When do you pay the piper? When is technical debt acceptable? bad? When do you pay your technical debt?
Technical debt forms when you are moving fast and making strides towards a goal. It happens when you are being successful and meeting timelines, achievements and delivering. It happens when you fall behind and you need to be fast and cheap rather than good. Sometimes it happens when you need to apply a quick fix – but often it is a slow accumulation that can build up over time.
What is it?
Technical debt is when you defer completing something fully (whether it is a feature, a process, a test suite) in lieu of moving something else forward. It happens when you know something could be done better, but you move on with the acknowledgement that it needs to be eventually done. It is where low quality can happen. It is when something is fast now, but will make things slower later.
What is the impact of it?
Technical debt rears its head when it is “risky” to change something. It is promoting code because it works but it is confusing to follow. It’s using a workaround so that we don’t have to spend the time/money now to fix. Is is leaving something not done correctly. It’s incorrect estimates when you try to do something later… and its generally invisible until you try to act on it.
Over time, that ‘undone’ thing gets harder and costlier to fix. Nobody likes technical debt.
Why is it bad?
It causes the worst bugs – regression. It causes the worst morale – rework. It makes it hard to change quick – lower productivity.
What causes it?
The biggest source of technical debt I’ve caused always relate to testing. Specifically not using unit testing, incremental testing. I love the idea of TDD, I preach TDD but I didn’t have a TDD upbringing. I’ve hired people who I knew were good at TDD and learned as much as I could from them. I’ve hired junior developers and had them focus completely on unit test writing to cover team technical unit testing debt. It is invisible but extremely valuable to day to day productivity – when you have test cases in place and you can monitor the evolution of your solution through the build process that can happen every day.
Coming from the package implementation, web development and heavier integration design and architecture stream of work — I’ve always had great success in figuring something out and making things work. It was one of my strengths and I used it often. One of the great thing about working with the developers at Barrington Consulting was learning from a team member who was steeped in theory. He does things by the book and lead me the right way of doing things. Our complimentary work styles allowed me to “figure it out” so things would function and he would “complete it right” so that it was well done. It was also a complimentary work style to making fast progress as we developed a rhythm on when to leverage each others strengths. It reduced the technical debt I was causing during building.
Paying technical debt is pretty near impossible. It is tearing down your work just to get back to where you started. It doesn’t make sense to spend 3 weeks getting back to where we are. Avoidance is the most powerful tool in dealing with technical debt.
When you working, you should always cycle through planning, testing the idea or approach or code, building something right the first time and then revisiting to see if it worked. More testing and launch. Make it easier for the next person. The focus of your work needs to be not just delivering the feature – it needs to be making that feature easier to work with in the future.
Plan. Test. Build. Plan. Test. Launch.