
Technical Debt: It’s not just the code - goldbabelfish
http://i-proving.com/2016/08/09/technical-debt-its-not-just-the-code/
======
andrewfong
If "passage of time" is a cause for technical debt, then this sounds more like
code rot
([https://en.wikipedia.org/wiki/Software_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).

~~~
adamconroy
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.

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

------
insomniacity
Google mirror:
[http://webcache.googleusercontent.com/search?q=cache:hYEf_w6...](http://webcache.googleusercontent.com/search?q=cache:hYEf_w6x3B0J:i-proving.com/2016/08/09/technical-
debt-its-not-just-the-code/+&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-b)

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

~~~
stieg
The irony here is bliss :p

------
EnFinlay
"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?

~~~
iajrz
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.

~~~
adamconroy
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.

~~~
iajrz
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 :^)

------
rco8786
About 4 sizes too small on the font!

