Overall, I haven't been happy with the Technical Debt Series.
For one thing, it reads like old cliches "Just don't do it" is just like advice to lose weight - eat less, exercise more.
People who are overweight are drawn by an entire system of forces to eat more and exercise less. The advantage to the less-healthy life is an immediate, short-term benefit but an erosion long-term. (Sound familiar?)
Telling someone who is overweight "Eat less, exercise more" doesn't help them. And, I am afraid, that's a lot of what into the series. (That, and brow-beat your manager.)
The sad reality is that when you cut corners, the "good job" and firm handshake of the boss is immediate, certain, and positive. The pain from cutting that corner is negative, delayed, and uncertain. Heck, if you're lucky, next time it might just be Somebody Else's Problem (SEP)!
This system of forces is very strong, yet completely invisible to many managers and executives. Thus, what option are technical folks left with but to browbeat management?
There has got to be a better way.
I gave a lightning talk at GLSEC on technical debt, and discussed it at some length with Steve Poling, who moderated lightning talks. Steve pointed out that the technical debt analogy is one that can resonate with managers and executives - people who understand money. His idea is that we study it further, creating a better explanation of the behavior, perhaps some measurements around it, some prescriptions to fix it, and then try those prescriptions, see if they work, and generate case studies.
That, my friends, is a lot of work. I believe it is worth it, so Steve and I are considering creating a non-profit, non-commercial Workshop On Technical Debt (WOTD). The workshop would be free to attendees, one to two days in length, and probably be located at a West Michigan College, probably around August.
If you are interested, leave a comment or shoot me an email.
More to come.
Monday, November 12, 2007
Subscribe to:
Post Comments (Atom)
1 comment:
from my tester's perspective I see a lot of it. One main aspect of Technical Debt is that it snowballs very rapidly and more and more time is being spent on rework. I really think that it just compounds beyond grasp of a single manager, single team. Sometimes there is so much debt that almost all of development is spent attending to it but on the management level it's called 'making progress' - it is a bit disfunctional, it also seems that people forget what it is like to actually 'create' software.
... well, just some loud thinking.
I think one of the remedies is to ask management to acknowledge 'going into debt' as it is being done rather than 'discover debt' afterwords. I can see the issue I have with being one of those 'overweight' people. I should eat less and exercise more but I don't make any 'notes' when I just ate too much and I don't make 'notes' when I didn't excercise. I think it would be useful to make some kind of chart of the last 6 months and point exactley where I 'gained weight' on a daily basis. Could this perhaps be done with technical debt? I think yes, One can have some specific entry/exit criteria as in-process work moves from one stage to the next - I keep thinking of Lean Software Development process this way, the queuing theory and batching sizes... well, forgive my blabbing - I just wanted to repspond with some half formed thoughts.
Post a Comment