That is moral relativism; you can use the same logic to excuse the American Slave-Holding Southerner in 1860.

So while I may not like the behavior, and I might not even think it’s right, I admit that it’s extremely rare for an IT line manager to rise above it.

I don’t look to IT managers to solve this problem. It is not the IT manager that actually _DOES_ the shortcut of “bad” technical debt; he simply exhorts and begs and pleads the tech staff to go faster.

It is the tech staff that makes the hacks, and thus the tech staff that needs to change behavior.

How do they do that? It’s pretty simple. Give estimates that are _responsible_. When asked to compress, negotiate scope, not features. Constantly improve our craft. Periodically reflect on the work we are doing. Mentor others and seek mentors. Most impotantly, never, ever make the same moral mistake of the Nazi Prison Guard when taking on tech debt: “I was just following orders.”

I’m not saying put you company out of business because you need to take a “principled stand”, I’m saying technical folks need to take responsibility for our tech debt and not blame management(*).

Now, I don’t want to eliminate all tech debt. I don’t even think that is possible. But if we can reduce it by a sizable fraction - say cut the average (bad) tech debt of a shop in half - we will significant increase the velocity of software development, thus increasing the financial stability of our companies, and our own sense of health and well-being.

The void of bad code is a pretty big hole - and empty bucket. If what we do can be a sizable splash into that bucket, well, I would be pleased.

Regards,

–matt heusser
(*) - If you look carefully at my comments during “the weaker brother” at tech debt, that is one thing I consistently did - took personal responsibility for my tech debt choices, instead of blaming the management bull-whip. We need more of it.

(hmm. Long Comment; I’ll blog this too!)

In hindsight, in my “Where did all this %$#@ come from presentation,” I should have made the point more clearly that these were sources of technical debt, not the debt themselves. In other words, all of these things can cause crufty code, but they aren’t the crufty code themselves. In that sense, I think my list is a bit more consistent with the general meaning of tech debt that we thought it was last week at the workshop.

Thanks for posting this.

Dave

I somewhat agree although what I saw during the exercise was the bunching up of items in the middle tended to be more massive than to the edges. Therefore the actual placement of the sizes was not entirely related to the actual number gaps. It also had to do with there were more items in the 3 and 5 range than the 1 or 13. Although, I do understand the effort relationship between the numbers might not be relevant but the idea of size using the spacing seemed helpful. Please try it out and see what you find best for your context. I am sure it would work either way.

I’ve enjoyed reading your blog very much. Having said that, it’d be an honor if we could work to repost some of your articles to our network (DZone). Please shoot me an email.

Cheers,
Wei Ling