typing and technical debt

technical debt: extra development work that arises when solutions that are relatively easy to implement in the short run are used instead of applying the best overall solution.

technical debt was coined by a developer and is a fairly well-known topic in the tech world.  i’ve now spent a year in an analytical business world and my team has struggled with this notion for essentially the entire time i’ve been here.  we’ve gone through cycles of accumulating technical debt and paying it down, and we’ve more or less survived.  it sure hasn’t been pretty, though, and i think part of the reason is that, to the business world, the notion of technical debt hasn’t been fully internalized.  the notion is understood, but perhaps the magnitude isn’t.

the other day, i was typing some notes and i realized that typing was an excellent analogy for technical debt, both in terms of a description of the problem and its magnitude.

when you’re typing, you periodically have “typos.”  slips of key-presses.  these are akin to the minor mistakes we make in our project work that inevitably happen.  better typists produce fewer of these typos, but they still occur (message here is that you can’t avoid technical debt by developing your workers or hiring better workers — it’ll always be there in some form).  there’s also a positive relationship between the speed of typing and the frequency of typos (as there is a positive relationship between the speed of cranking out project work and the frequency of errors).

one way to deal with these typos is to watch the screen while you’re typing.  this is akin to checking your work as you go or at frequent intervals.  when you do this, you catch these typos quickly and all that’s required to fix the issue is a split- to full second or two of hitting backspace, fixing the error, and re-typing.  however, there are a lot of reasons for not looking at the screen while you’re typing (perhaps you’re copying something from a written piece of paper so your eyes are on what you’re copying).  when you DO glance at the screen, you’ll likely find some errors that are paragraphs ago, or are at least too far away to make the backspace/re-type trick cost-efficient.

now you’re in trouble.  instead of performing the quick backspace/re-type trick, you have to switch over to your mouse, navigate the cursor to the error, click, backspace/delete, re-type, move back to the mouse, navigate to where you left off, click, and resume typing.  obviously, this process is much more time-intensive (at the very least it takes twice as long, and four to five times as long is probably more accurate), despite the fact that there’s absolutely no difference in the magnitude of the error.

this is technical debt in action.

when an error occurs, debt is incurred.  from this point on, interest is accrued.  if you attack the problem immediately (our first approach), the interest is negligible and the amount of time it takes to solve the problem is essentially constant for each problem.  however, if you don’t attack the problem, the debt starts compounding.  roughly speaking, the longer you wait, the longer it’s going to take you to fix the problem. obviously, in the typing example, this isn’t perfectly true due to the piece-wise nature of the problem (switching to needing to use the mouse causes a jump in the debt, or time it takes to solve the problem), but you get the idea.

until now, we’ve only discussed the types of errors that you wouldn’t know existed unless you were watching the screen.  these errors are accidental, and can be easily excused.  they’re caught through checking processes as designed.  however, there’s another type of error-neglect cycle that’s less excusable:  you know when you’re typing and you can just feel that you made a mistake?  maybe you didn’t quite hit the key the right way or you “fat-fingered it” and hit an adjacent key (or two)…

there are two ways of handling this type of error: you can either do a quick check (cost: split-second) or you can hope for the best and continue typing.  unless you’re paranoid and you think you made mistakes all the time when you actually didn’t, the tradeoff for the quick check is very good (i.e., it’ll save you a lot of time in the long run).  translated to project work in the real world, when you start to get the sense that something’s wrong with what you’re doing, stop immediately and check it.  it’ll save tons of time in the long run.

the real-world cost of not checking immediately when you suspect something is wrong typically looks like: realize output is wrong, go back and try to figure out what you did, try to figure out what went wrong once you’ve figured out what you did in the first place, make adjustment, validate output.  this can clearly be a lengthy process, and the time spent paying down the interest (mostly the “figuring out what you did initially” piece) was almost certainly not built into the project schedule.  this leads to needing to speed through your current work that you were stealing time from to fix the old work, which leads to more errors in your current work, which leads to……

i mentioned that this type of error-neglect cycle is generally less excusable.  there are circumstances, however, in which exceptions should be made.  i’ll eagerly admit this.  sometimes, even when you’re pretty sure you didn’t hit that key quite right, you just need to block that possibility out and power through.  maybe you have a very important short-term deadline to hit and you’re confident that your client will get the gist even if there’s a typo or two.  there are times when this is a wise tradeoff.  however, it seems that many people, through some sort of false confidence or blind hope that it’ll all work out, believe this tradeoff is justified far more times than it actually is.