Code As A Liability
Jim Shore asked recently about what metric might be used to measure technical debt.
Now, sigh and groans over the word ‘metric’ aside, his first suggestion
prompted some thought; namely, SLoC. This was interesting, mostly
because SLoC was once used as a measure of productivity, but here it
was something different. I didn’t like this idea, simply because it
meant that no matter how hard you worked, how mercilessly you
refactored, you would always be increasing technical debt. In other
words, no matter what, you lose. I don’t find this appealing. We went
around the houses a bit talking about using SLoC per feature, or SLoC
per story point, but something very interesting came out of the
discussion.
As software developers, and particularly as a micro ISV, we would
think of our code base as our biggest asset, but how often do we think
of it as potentially our biggest liability? Why a liability? Because it
costs money. It costs money for others to spend time understanding it
(if you aren’t a 1 man band), it costs money to change it, it costs
money to test it, to bugfix it, to refactor it, to add to it, to
integrate it. These are the times that you will notice the interest
payments on your technical debt.
As a micro ISV, technical debt payments can be crippling. Imagine
not being able to make use of you’re new employee because your code is
too hard to understand, because it does not clearly express intent.
Imagine not being able to add a new feature because you’re too worried
about the impact on the stability of your codebase.
The solution is clear. Don’t let technical debt accumulate to a
level such that the interest paments become a barrier to progress. Your
code is your greatest asset, don’t let it become your greatest
liability.
Interesting timing, I was just thinking about technical debt and my own uISV earlier today…
I’ve realized some real differences in how I approach technical debt
with my uISV compared to my “previous live” running a team of 60+
developers. One one hand, I feel more willing to take on debt at times,
because I have the full view of the software infrastructure, at both
the high and low level. With a big team, that knowledge is distributed
across many people and it’s harder for any one person to make educated
decisions on what types of debt are worth taking on and what will end
up costing many times more down the road, and senior
developers/architects are often more removed from the small decisions
that often compound over time to result in the “surprise debt” that
tends to be insidious on big projects.
On the flip side, because I get to dictate the pace and schedule of
development, I have the ability to make the decision to take the time
to wipe out debt before it starts to compound – I can take half a day
to revamp particularly ugly pieces of code or to refactor one section
of the infrastructure to better support future work without having to
worry about arbitrary deadlines that I have no visibility into.
I’d be curious to hear if others have similar experiences, and how
they change (or don’t) as you start to bring in more developers to
assist with the work.