Technical Debt: It’s not just the code | Hacker News Reader

Technical Debt: It’s not just the code

i-proving.com

55 pointsgoldbabelfish13 comments

If "passage of time" is a cause for technical debt, then this sounds more like code rot (https://en.wikipedia.org/wiki/Software_rot) than "debt".

IMHO, "rot" or "wear and tear" is actually much better metaphor to use with management than "debt" or "unhedged call option". Financial terms implies a degree of precision to the cost, and for debt, it also implies some predictability.

In reality, code that's fine today may become problematic tomorrow for all sorts of reasons -- some internal to the organization, some external, some predictable, some not. Like rot, the exact amount of code that needs refactoring or fixing is difficult to quantify precisely. Like rot, there's often some (sometimes crazy) workaround in lieu of fixing the rotted bits. And just as we can design our structures in ways that are less likely to rot over time, we can write code that's less likely to become problematic in the future (with the corollary that the decision not to invest in better initial infrastructure today may result in problems tomorrow at some unknown time and place).

I've always thought that 'debt' is a poor analogy. Systems get replaced / rewritten / superseded / thrown in the bin... all time, and that is where the debt analogy fails.

Its obviously semantics, and I'm not advocating sloppy programming / architecture, but the term is both inaccurate and leads people to blinkered thinking.

It's not just about the code! You also have to establish a database connection.

Google mirror: http://webcache.googleusercontent.com/search?q=cache:hYEf_w6...

"Error establishing a database connection" — it is almost always design or architecture decisions, like not caching :)

The irony here is bliss :p

The blog has a "share" link to delicious and digg. Something tells me he's been accumulating technical debt for 6 years

Is sardonic the appropriate word for this? I think it is...

"I’ve found that the definition is more useful to both developers and managers when it encompasses all debt of a technical nature."

Isn't this the definition that everyone uses?

Sadly, no. I've not seen, say, using legacy source code management tools or development lifecycles described as technical debt; I'd not thought about it that way myself, I'd just thought about it as outdated practices. A quick hack or an ugly workaround? Yes - and even those I've rarely seen management allocate time to pay back. Reframing the other issues may help communicate with management on how to make all the process and product better.

And quite possibly the whole system was replaced within a few years and it turned out that management were correct in not letting your team waste the organization's money trying to be purists, and probably over-engineering at the same time.

I see how you'd imagine that, but it's not so. It wasn't about purism or over-engineering - it was actually sensible stuff. Less like "let's use latest version of framework X" or "let's change the organization's stack!" and more like "Let's set up this new project in a supported version of the JVM instead of reinstalling the legacy one in the new server, please? I looked it up and this newer version of the JVM is certified to work properly on that platform." Or like the time I tried to get a certain organization to take up version control, which was rejected because someone sometime way back when managed to lose information while merging in cvs and the supervisor didn't feel comfortable with a vcs, distributed or not (I'm told merges are still done manually by the supervisor using windiff).

And I offered to do the work necessary on my own time on both these occasions, with safeguards so we could fall back into the status quo at the slightest signal of trouble.

So no, while I can be - and am - passionate about new tech, I cut my teeth developing large scale systems that had to be up at all times. So being conservative at work is second nature to me, even if I play with unstable or experimental stuff all the time.

It's... not cool that you tried to be clairvoyant instead of curious.

Maybe in the future you could ask "How did that turn out though? Were the systems changed, that you know of? Did you consider that management didn't want the team to waste the org's money trying to be purists or over-engineering? Did the decision maker have a technical background?" or other such questions, in order to later make an informed statement.

On the other hand, the way you stated it made me think you've had an awesome experience with great management, so congrats on that, I hope you keep choosing amazing teams to join - if or when you change gigs :^)

About 4 sizes too small on the font!

Reply on news.ycombinator.com