Technical Bankruptcy

Just read an excellent article on the concepts of and incurring and paying back the “Technical Debt” that accumulates on poorly executed software projects. The idea is that one contributes to a pool of technical debt or credit, analogous to our economic and financial status. One of the great topics discussed in the article encapsulated the very real need for diplomacy when confronting your projects debt and impending bankruptcy.

“There’s a high probability the messy code you have to deal with was written by someone currently on your team. It’s important that you take this into account when reasoning about the code in its current state. Hurt feelings lead to defensiveness that, in turn, leads to slow going on the improvement train.”

Now if you are incurring a technical debt at the architecture level you are in dire straights and need rescuing by experienced designers. Unfortunately poor architecture will not only incur technical debt but probably QA and managerial debt also. I came across another interesting blog where the point was that “Pro’s don't make do”. We simply have to hold our selves to a higher standard when it comes to preparation and execution of software projects, starting with the acquisition of the appropriate tools and leaders who have the appropriate experience level for the task at hand.

The truth is I have learned more about managing software projects from failures I have encountered than from my apparent and immediate success. With that said here are a list of things that can lead to the worst kind of technical bankruptcy:

• Setting external target dates without internal reviews are a remedy for disaster.
• Having technical staff who do not understand the complexity of their own work will immediately lead to incorrect work estimates.
• Implicit design and architecture are useless for most people, and especially disastrous for developers.
• If you are unable to setup reasonable target dates and completion points throughout your project, you may not fully understand what you are delivering.
• Setting product release dates before you fully spec your project or understand the nature of the problem.
• Hiring a project manager who has not experience at least one epic failure from which they have learned a valuable lesson.