There seems to be a theme developing in these posts. I start to see everyday situations and then relate them to everyday happenings - then attempt to do some analysis. Today's is no exception.
Ward Cunningham introduced us to the concept of technical debt in a 1992 experience report. Quoting from wikipedia, "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. " An excellent follow on blog post from Steve McConnell (at http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx ) expands on the point.
I am going to think a bit more prosaically! I was sitting at the computer minding my own business yesterday afternoon, when from behind me I heard a crash. A picture had fallen off the wall, spreading glass shards everywhere. On closer inspection, I saw that the method of attachment to the wall was inadequate. It was a simple nail, not a proper hanger. What's this to do with technical debt you may ask? Well, presumably when the picture was hung, the hanger (perhaps me) chose a quick and dirty solution - a nail. I could perhaps have used the proper fixture - but that may have entailed considerably more "development effort". I would have had to drive to Lowes or Home Depot to buy the fixture, install it properly... you get the point. Oh and of course there was a deadline. We had a party that night and had to have the picture hung.
That was about 8 years ago. Eventually the hanging approach failed and I now have to pay back the debt for my slapdash method of 8 years ago. The repair cost will far exceed the cost of "doing it right in the first place." However, I made the decision to do it the way I did because I didn't have a good handle on what the longer term implications would be and because I had a deadline. These are both key observations.
When we build systems we often don't actually know what the long term implications might be. We don't for example know what "long term" actually means. We often can't explain why doing it right is more cost effective "eventually". I, for example, wasn't prepared to say to madame, "I'll need to go to the store to get the right fixture, hold the party until I come back and put up the picture." Nor was I prepared to say, "let's not have that feature in the house until after the party."
The point here is that we often make conscious choices about the way we do things. These may be suboptimal in the long run - and they will come back to bite us. However we must suborn the future to the current to make sure things get done.
What is more clear to me is that we understand the operational implications of our choices. We need to build our solutions, "hard enough". We need explicit statements about the "-ilities", so we can apply the right amount of engineering. Let's make sure we get the failure stories as explicit as the success stories when putting our plans together - when deciding what goes into an iteration. Make sure we incur the technical debt for the right reasons.
Posts
Business Process Management: Easier said than done
14 years ago
3 comments:
I think a key point is that, given the same situation again, you still would probably choose the quick & dirty approach for hanging the picture. Too little time, too much to do, just get it done. But maybe, with the knowledge of the consequences, you would have scheduled a near-term follow-up fixup with the right hardware. Business people may often (always?) choose the quickest option even given the full explanation of the consequences, because the fixup may happen far out enough into the future to be someone else's problem. One possible solution is to immediately schedule the resources for the correction at the point when the decision is made to take on the debt; that is, give it a present-day impact. I dont think that will really change behavior, but taking that step will ensure that you quantify the impact with the estimated resource hit. Then, when the business or the CIO next complain about the ratio of IT budget going to maintenance vs. new development, you can show how much maintenance you've added to the pile via conscious choice.
Have you checked all the other picture hangings?
As Gene says, the point is not that you did something quickly, but that you didn't pay any further attention to the matter. Short-term debt is one thing, forgetting about it (as we all tend to do in such trivial matters) is quite another.
There is further discussion of this post in the Lenscraft group on Linked-In.
Post a Comment