A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
A view on Technical Debt, and why you should pay it off early:
Interesting. I don't think the Millenium Bug is a good example of this, though; my impression is not that people knew it was a problem in the making, but rather that they just never stopped and thought about exactly how the system would behave when it rolled over to zero.
I'm familiar with the phenomenon, but "technical debt" is certainly a catchier term than "stuff I haven't gotten around to yet."
Yes, this is a common problem, but I think many projects suffer from a more sinister *unconscious* technical debt.
In other words, mistakes, short-sightedness, and yes, stupidity that accumulate over months and years of a software project. This isn't just the code, its the requirements gathering, design, documentation, and the process itself.
I've seen this in subtle things like:
The Build Process: "Build Script? No, Fred does all of our builds on his machine in Visual Studio. What? Oh, yes, he also develops on that machine. That's funny, yes he DOES keep saying Works On My Machine (TM)"
Configuration: "You have to tweak some settings when you install this software, but I'm not sure which ones - we just ask Joe whenever we need to do it"
Documentation: "It crashes unexpectedly? Oh, you need the latest version of FOOBAR.DLL, that's a well known problem"
Development Process: "We're using Extreme Programming, but we omitted most of the practices so that we just write code as fast as we can. No documentation, no tests, no code reviews, and we don't have any contact with the customer."
Management: "Hiring a QA staff is a waste of money, you developers should just do your own QA, quit being lazy!"
Teamwork: "That's not my problem, its a bug in Joe's module, go talk to him. Oh, you did and he blamed me? Bastard! Well, I can't fix it, it's probably Microsoft's bug"
Sunday, March 20, 2005
It seems like Technical Debt should just become "feature requests" and be evaluated along with all the other feature requests. Some "features" may just keep slipping, because there's always something more important.
It think there is an argument that these "left over" "todo's" get swept under the rug in the excitement of a product launch/new release.
But that probably happens regularly if you don't have a bug reporting database (or list, at least.). And if you DO have such a db/list then merely leaving those leftover "debt" items in the list means they are NOT forgotten. You can reevaluate thier importance after lanuch. perhaps a "can wait till next version" becomes "critical".
Not sure I agree.
Things left are only a problem if they end up biting you - there are probably examples of such short-term fixes in almost every bit of code out there.
It's too tempting to fall into a perfectionist mode (it's good or bad, broke or fixed) whereas maybe it would be better to take a risk-based approach: how likely is this to bite me, and how big is the consequence if it does?
Monday, March 21, 2005
Well put, Rich.
I look back at our 10 year history and see where we could have done things better. But, at the time, you don't know which things need to be better.
So, for 8 years I did the bare miniumum, and things weren't perfect... but the CUSTOMER DIDN"T KNOW THIS. It was internal messiness.
Now that we are comfortable, profitable, and I have lots of time, I'm a perfectionist. And I've gone from coming out with 1 program every 3 months or so to nothing in the last 4 years.
It's because I am now trying to look out 10 years in the future and use all the latest methodologies (XP, Test First, etc.).
Maybe I should have stopped at just XP's "do the minimum necessary for it to meet the customer's needs" :-)
Heh heh... Good article. I refer to the same phenomenon as "frictional drag." The longer you delay refactoring & cleaning up your crap, the more frictional drag manifests for all who try to work on the thing, or use it in their own projects (e.g. the learning curve for developers to discover workarounds for all the quirky/buggy/unexpected behaviors, or to walk down the hall 50 times to ask Guru Joe how you do this or that). An activity that should take an hour takes a day, then a week, then a month... The only reason cleanup seems too expensive is because frictional drag doesn't have its own column in the spreadsheet, but rather manifests as a general slowdown in everything. If drag _did_ gave its own column, cleanup would seem downright cheap by comparison :-)
Monday, March 21, 2005
I have written a series of addendum's to what was said here (which has been interesting): http://www.scaletrix.com/nuno/blog/2005/03/on-flexible-architectures-and-rigid.html
People knew about the Y2K bug in 1970, but put off dealing with it for 25+ years.
Wednesday, March 23, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz