This is MichaelDunham's Typepad Profile.
Join Typepad and start following MichaelDunham's activity
Join Now!
Already a member? Sign In
Recent Activity
In answer to your questions - I haven't really followed studies of "technical debt" although I have been aware of the concept for sometime. On the other hand, my experience with many developers is that the term has been that it is taken somewhat lightly - "we have some technical debt in the way we developed the interface, it is showing up in response times for end users.." In other words, it is some unknown quantity sitting out there, making the application seem slow and causing losses in productivity and adoption. In all honesty, there are costs on both sides in most situations and counting the costs only on the side of fixing the code is a least short sighted. The reality is that most issues in code don't arise out of considered choices. They are made in an instant by one developer who makes a bad or uninformed decision on how to implement something. They become apparent when something odd starts happening (usually much time has past before it surfaces) or a change in the app suddenly brings the house down. They become costly because at that point, the problem can be very hard to pin point and when it is it may impact many lines of code in unexpected ways and even more important, users are impacted and productivity, adoption and/or cash flow become seriously threatened. The costs can quickly spiral out of control. Automated code review tools are certainly worth considering - but they can't quantify the value of each item they encounter and there is only so much they can cover. A code review by an experienced senior developer or architect can often find things that are more critical to the overall design of the application now and in the future. Also, many developers don't really understand the reports the tools generate. If they don't start using the tools at the beginning of a project with the oversight of a more experienced developer, there is no way they can make the decisions they need to and improve their development practices. Applied too late, it is a real show stopper. It can create a deer in headlights situation where no one knows what to attack or what could become more serious. It comes to this - most QA procedures only clear issues against requirements and functionality of a feature. If the code doesn't create a problem in that limited context, it is assumed to be fine. When it breaks down the road, is when everything will come apart. I see what is called "technical debt" in most cases as serious risks that can eventually become even more serious bugs. We've dealt with this ever since we started developing computer applications. There is nothing new about it. It is critical to be aware of but fixing the problem is a process of applying code reviews (automated and/or manual), peer programming, and best practices from the beginning of every project. There is no good way to attack technical debt once it is in place. Fixing one issue can create many more and the house of cards comes tumbling down. For that reason, saying there is a lot of existing technical debt is the wrong thing to consider. It is an unknowable quantity and it can't be repaid in the majority of cases. The possible failure in the interaction of services on the Internet is no more or less critical than some number of individual failures on servers in private installations. The only thing that can be done is to use best practices and reviews from the start and to continue to improve developer compentancy. So yes it is real, but no, I don't think the calculation is credible or the right thing to consider except to get executives to include code and best practice reviews in all projects from the start. Just stop saying it is too costly and time consuming now and become aware of the far higher costs the risks incur down the road.
1 reply
MichaelDunham is now following The Typepad Team
Oct 6, 2010