, , , , ,

Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

Wonderful quote and perspective provided in one of the many Product Management blogs I follow, this time a post titled The Broken Windows Theory of Technical Debt in the Mind the Product blog. And I understand all too well the perspective from both sides of the equation.

As a Developer

I recall early in my career when I was coding the UI for a massive project that had to be delivered in what I thought were unrealistic time-frames. My colleagues and I were having the discussion about being able to deliver fast/cheap, but low on quality … or with quality but perhaps a longer delivery cycle. But not necessarily both.

Given the importance of the project, as well as the constraints the team was place under, I took a few short-cuts.  Nothing drastic, mind you … just a few hard coded definitions in an otherwise table-driven environment.

I delivered my portion of the project on time, on scope, AND without bugs!  But looking back, I did deliver it with technical debt that somebody had to go back and fix.

As a Product Manager

Those types of little decisions in the moment now drive me nuts as a business owner! While I can empathize  with developers who feel the need to deliver “quick and dirty”, it doesn’t make it any easier to digest when it comes to the next release and I am having to sacrifice capacity because of technical debt!

Oh and by the way, I am a believer in Agile, but following it shouldn’t come at the expense of other good product management practices (i.e. – what is expected from you as a Product Manager hasn’t changed just because the development methodology has), nor should Agile be used as an excuse for delivering sub-standard code (i.e. – when I say MVP, it doesn’t mean it’s OK to sacrifice functionality for the sake of expediency).

Here’s the reality … we think we can make up for the technical debt after the stress of this particular project is done … but the next priority project is just around the corner, and chances are it is just as important as the previous one … meaning getting back to that nothing drastic decision will not be as easy as I thought back then!