Even after reading the article, I think that folks often don't understand that Technical Debt is not a "bad thing" but a thing that must be understood and managed.
When you understand this, it puts software engineering into a very clear perspective.
That's true, but how do you manage it? Especially when it's so difficult to measure in the first place.
One idea that popped into my head would be to keep a running tab of technical debt that's being accumulated in a project. It's tough though, because developers who are in "accumulating debt" mode tend to be the ones with the least amount of time to spend on upkeeping a document that tracks their debt.
I open a ticket saying things like "this needs to be documented, estimate is X hours to document fully; don't forget gotchas A,B, and C", or "fix this corner case that occurs X percent of the time", or "this will run slowly when traffic reaches X because of Y" and such, giving it a priority that indicates exactly what the technical debt would cost if it wasn't resolved (super low priority is really cheap, no big deal, extremely minor inconvenience). This is partially so I don't forget about it, but also to document that something isn't as clean as it could be. These are not hard and fast "measurement" numbers, but by looking at the ticketing system, you can get a general idea of how far things are behind.
It also gives you a list of alternative things to work on when you're getting burned out on the active tasks.
It's managed by the thought process of the programmers. A good programmer knows when and where the technical debt is and wants to pay it off. If the programmers don't understand this or don't care, there's not much that can be done. Teaching works, up to a point (but no further).
You can't manage this with documents for the same reason you can't manage thinking with documents.
If I were going to try anyway, and were working with a team of more than 2 or 3, I might put a big piece of paper on the wall and ask everyone to write on it whenever they notice technical debt. The bigger the issue, the bigger the note. Maybe use different colors for different parts of the system. After a while, patterns would emerge. But the real purpose of this would not be to track accumulated debt; it would be a device to encourage people to talk about it and think about it.
"It's managed by the thought process of the programmers." -- In enlightened organizations, sure.
Is it unprofessional to allow managerial deadline pressure to influence code quality ?? At what point is it justified for a programmer to say "No"? At what point is it wise?
Is it unprofessional to allow managerial deadline pressure to influence code quality
Actually, yes, I think it often is. If you're paying me to write code, then it's incongruent for you not to rely on my judgment about how to do it. If you don't like the results I produce, you're well within your rights to find somebody else. But you are not within your rights to hire me and then block my judgment about what the system needs.
The vast majority of the time, it's not a matter of explicitly saying "No": if you even get into that conversation in the first place, it's probably game over. Asking for permission to do a good job is likely to meet with, "No. Do a faster and cheaper job instead." That's an argument the programmer will never win. And rightly so, one might say! - because of the lack of self-respect they're demonstrating by such behavior. One thing I've learned over the years is that it's my own fault if I don't stand by what I value and know. (Well, partly learned, at least.)
If you want to be professional, don't act like a servant.
Edit: I was thinking about why this is by and large so poorly understood by software developers. I think part of it is that programmers tend to be younger. They haven't had time to learn this the hard way, and there is a large authority and status gap between them and their (usually older) managers. Perhaps another aspect is that many programmers are introverts and thus less likely to advance their own interests and judgments, even when they're right.
I find this interesting because those are both reasons why the hacker renaissance and the corresponding startup explosion are really good things. When the hackers own the product, the situation we're talking about is much less likely to arise.
Tech people can be as bad as anyone else when it comes to this kind of stuff. Put one hacker "in charge", and make another hacker a subordinate, and suddenly you've got these kinds of authority issues. In fact, they might be worse, because hackers are always fond of thinking that they can do things faster and better than the other guy, and they're especially fond of being confrontational about technical issues.
Other than that, I agree with you. Last year, I heard a talk given by two co-founders (one technical, one not), who were discussing their working relationship. The tech guy got a big laugh with this line (paraphrased):
"Every once in a while, [my cofounder] gets on my nerves with questions like 'why can't it be done sooner?' It's really helpful to be able to answer 'because fuck you, that's why.'"
That's a luxury that most programmers get to experience, unfortunately.
To me 'managing it' means managing risks, which often means managing long-term expectations. Debt can't exist without risk, even the technical debt mentioned here. The way you manage that risk really depends on project-specific variables - timeline, budget, staffing. You might allow a grievous hack to get something to market now, with the expectation that you will have more staffing to clean it up later. Or you may invest in a robust design now because the expectation is for staffing to be cut to 1/2-head for the next 3 years, and you need something that can adapt under that risk profile.
I leave a lot of TODO and FIXME comments in code (which are then tracked and highlighted by my IDE). These range from code that may actually be broken on certain rare or unexpected corner cases (though not dangerously so), to known inefficiencies, to areas where the rough idea for a much better approach exists but can't yet be fully developed.
Very roughly, they are a measure of known technical debt.
Same here (in gvim). I also like pylint's default behavior of issuing warnings where it finds these and penalizing the code's final score in the report -- it's a proxy for code problems that have been silenced or worked around, but still need some attention later. Integrating this info with a bug tracker seems like a good idea too for sufficiently complex projects.
I think I wind up adding new ones at about the same rate as old ones disappear, but I'd have to run a report over the history to know for sure.
It's always nice when I come across a note that's been made irrelevant by other parallel improvements along the same theme -- even though the note wasn't the impetus for the other changes. It's like finding a $20 on the street!
I had seen a Martin Fowler article on technical debt before but the link to Ward Cunningham is new at the least.
As a part-time economist, it occurs to me that the debt metaphor actually doesn't work on some levels: Companies constantly increase their monetary debt, since THAT can be paid through increased profits. You actually wouldn't want a company that grew without increasing debt - that would be wasted resources. Technical debt is much worse to accumulate since it can only be paid by increased development time.
Also, one accumulates technical debt whether one wishes to or not. This is because often the only way to understand how to do a system right is to first do it wrong.
Even after reading the article, I think that folks often don't understand that Technical Debt is not a "bad thing" but a thing that must be understood and managed.
When you understand this, it puts software engineering into a very clear perspective.