Paying Off Technical Debt

We don’t get spam about how to consolidate our technical debts. :-) Image credit: Alan Cleaver (Flickr)

“Interest never sleeps nor sickens nor dies; it never goes to the hospital; it works on Sundays and holidays; it never takes a vacation; it never visits nor travels; it takes no pleasure; it is never laid off work nor discharged from employment; it never works on reduced hours. . . . Once in debt, interest is your companion every minute of the day and night; you cannot shun it or slip away from it; you cannot dismiss it; it yields neither to entreaties, demands, or orders; and whenever you get in its way or cross its course or fail to meet its demands, it crushes you.”

J. Reuben Clark

In my recent post about how organizations forget technical debt, I glossed over some important details. When you’re in debt, you have an obligation to pay somebody back. So: with technical debt, who must you pay, and how?

More than just a code problem

A simplistic view–one that I’ve used for years–understands debt mainly as a deficiency in code. In this view, you pay yourself back by making the code better. Most discussions about technical debt take this view. It’s natural, and true, and useful.

However, I don’t think it’s the full story.

It’s good practice to borrow money from yourself. If you do things this way, you save a bunch of capital, and then you borrow against your own reserves. Paying yourself back consists of transferring money back into your own savings.

This is hard, and making large purchases this way requires years of prior planning and discipline.

A more common way to borrow is Continue reading

Code Isn’t Art

Programmers, tell your inner artist to shut up.

One of the defining aspects of the Ruby programming language is that it is very flexible. It takes a very UNIX-like approach of having a few simple and well-defined functions that allow you to build rather complex systems. Unfortunately, it also ends up encouraging programmers to start thinking of their code as art, and then they start writing “clever” code. There’s nothing necessarily wrong with finding an unconventional solution to a coding problem, but that often falls apart when you have to involve another human in reading your “art”.

Let’s use an example from SQL of a “clever” solution. Take a look at the following query:

SELECT cl.Language, c.Name AS “Country Name” FROM CountryLanguage AS cl INNER JOIN Country AS c ON cl.CountryCode=c.Code SORT BY c.Code

How long did it take you to read that query? Probably a good minute or two because you had to expand out all of the aliases to figure out what it’s doing. Compare that to the unaliased version below:

SELECT CountryLanguage.Language, Country.Name AS “Country Name” FROM Country Language INNER JOIN Country on CountryLanguage.CountryCode=Country.Code SORT BY Country.Code

As you can see, it isn’t a “clever” query, but it sure is a lot more readable to a third party.

A lot of programmers will probably come back with “so what? I can read my own code and it gives me the result I want.” The fatal flaw here is that code is written not for machines, but for people. (Odds are good you’re also not going to be the only person that sees that code.) If we were writing for machines, you’d be using pure binary. All programming languages are made to give humans a way to express this in terms that are much more easily understood. Heck, SQL had an explicit design goal to be easily understood by accountants that needed to work with a database. The human element is crucial.

This is especially frustrating for those of us in support roles. I have a long history with SQL, some PHP experience, and I’ve done some dabbling with Ruby on Rails, but that’s atypical. Most support people don’t have any programming experience. What if they’re in a situation where they need to decipher the scripts that support a product or, heaven forbid, peruse the source code to try and find the cause of a particular error? They can probably figure out verbose code from having dealt with pseudo-code examples but will run straight into a brick wall if a programmer decided to be “clever”. Now the engineering team has to be drawn into something that could have potentially been resolved by support.

The question you have to ask yourself is if the ego boost from “clever” code is worth the increased work created when others don’t understand your “art”. I’m going to bet that your team members, members of supporting teams, and any management you report to won’t look favorably upon it.


Jesse Harris has been a geek since cutting his teeth on the Commodore 64 in pre-school. He currently works in support at RSA, the security division of EMC, and has been doing support, systems administration, and web development for 13 years.

Good Code Is Balanced

In my first post about what constitutes “good code,” I claimed we were dealing with a complex question. This is why I distrust short answers.

So many competing concerns must be balanced to achieve goodness:

  • Testability
  • Maintainability
  • Short-term revenue pressures
  • Long-term strategic value
  • Performance (many aspects)
  • Scalability (up, down, across)
  • Ease of use
  • Supportability
  • Conceptual integrity
  • Alignment with the skills, temperament, interests, and tools of the team that owns it
  • Cost vs. benefit (for some problems, quick and dirty is definitely “right”)
  • Simplicity (separation of concerns)

More items undoubtedly belong on the list. Quite a balancing act!

Someone’s got this “balance” thing down! Photo credit: joãokẽdal (Flickr).

Action Item

Pick a module, application, or subsystem that you know well, and grade its code according to how much its coders emphasize a few different dimensions (e.g., performance, testability, scalability, ease of use). Do you like the balance? Are any attributes being neglected?