Paying off technical debt
0

Paying off technical debt

David Gammel asked the following in the comments on my previous post on technical debt:

Do you think the technical debt has to be paid off with a balloon payment? It seems to me like you can’t really pay off this kind of debt on a 30-year fixed interest model, it all comes due at some point in the future and must be paid in full, at once, in order to move beyond it.

Or can you refactor code consistently and in essence pay it off with small payments over time?

I think it very much depends on the form of debt. As a matter of habit, whenever I work on code in an application that seems difficult to understand or badly written, I take the time to try to improve it where possible. I think that constant weeding and pruning are the key to maintaining a nice code base, and nobody seems to know or mind when what would have been a one hour fix turns into a two hour fix because you went ahead and made things a little better while you were in that code anyway.

On the other side, there are cases where technical debt has to be paid off all at once. For example, one application I work on is still running on Rails 1.1.6. Rails is now at version 2.3, and there have been a multitude of changes that would make this application easier to work on. Unfortunately, migrating up to the latest version of Rails is going to take a fairly substantial chunk of time, and it all has to be invested at once.

In both of these examples, good unit tests are the key to being able to pay off the debt at all. In the first case, making “improvements” to the code while you’re working on it can be risky if you don’t have the tests you need to insure that you haven’t broken the business logic in an effort to clean things up. In the second example, having a solid suite of automated tests makes it possible to rapidly locate and repair all of the problems you run into when making a large set of changes.

I suppose then that I’d argue that inadequate tests are one of the most painful types of technical debt that a project can accrue. On the upside, it can be paid off gradually.

A soldier’s recollection of Gitmo
1

A soldier’s recollection of Gitmo

The Guantánamo Testimonials Project has the written testimony of a US military policeman who was stationed there at the beginning. I expect many more such stories will be told over the next few years:

At 0700 hrs the next day I reported like I was told, and was placed in 1st platoon. Then I was told that we would be deploying to Guantanamo Bay, Cuba, within the next 24hrs. It was not until later that afternoon that we were told that we would be starting and running a detainee facility, not an EPW (or Enemy Prisoner of War) camp. We were told that a detainee camp had never been ran before, and that this would be the first time in history this had taken place since these people would not fall under the Geneva Convention.

There’s tons of awful but enlightening information in the interview. For example, it makes it clear that the infamous “IRF” teams were used not to bring out of control prisoners under control but rather to punish the noncompliant:

As far as IRFing, when I was there, it went somewhat in this order: (1) The block guards would have a problem with a detainee (not listening, maybe saying something, or not following rules). The guards would then contact the duty officer for that shift. We were told “If you were working a block and was having a problem with one of the detainees, and you couldn’t handle it, or get it under control, you should call the duty officer,” who was usually a E-7 (Sergeant First Class) or a 0-1 or 0-2 (First and Second LT). They would come to the block, assess the situation, and make the decision whether to take “comfort items” away or call the IRF team into play. If the latter, then (2) The duty officer would come to the block with an interpreter and tell the detainee to do whatever he was told to and, if not, the IRF team would be called upon. (3) Once the IRF team was called upon and arrived on the block there was no “I am sorry I will do it” from the detainee; the IRF team was going to enter that cage and hog tie that detainee.

Reading the interview what stands out to me is not just the horrible treatment we’ve inflicted upon detainees, but the burden the government placed on the troops who have served in Gitmo and elsewhere. One principle of leadership I believe in is that you should never ask anyone to do anything you wouldn’t do yourself. I can’t help but wonder whether most of the officials who designed and implemented the detention policies after 9/11 would be willing to personally subject prisoners to the treatment that they prescribed.

Technical Debt
4

Technical Debt

The other day I was reading an article by Martin Fowler in which he referred to the term technical debt. He credits Ward Cunningham for coining the term, which is defined thusly:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

This is a nice, business-y way to discuss a problem every developer is familiar with. You could publish a blog just on ways projects incur technical debt and how to address those problems. In fact, I’d argue that one of the primary jobs of a team leader or manager on a technical team is to spot places where technical debt is being incurred so that it can be addressed later on.

The burden falls on the person leading development, because nobody else involved in the project is going to take care of it. The product manager (or project manager) are properly focused on budget, schedule, and specifications. The quality assurance team is focused on making sure the application produces the right output given the right input. Only the developers themselves can be responsible for reducing or avoiding technical debt while addressing the other audiences.

I think that most of the worthwhile fights that developers have with other members of the team are over issues of technical debt, it’s just that few people refer to it that way.

Expect more posts on technical debt in the future.

Germany’s old car repurchase program
5

Germany’s old car repurchase program

The Truth About Cars writes about a German program that pays drivers to get their old cars off the road:

The attack of the aging automobiles is caused by the Abwrackprämie, cash for clunkers, paid by the German government. Since January 14th, 2009, owners of cars nine years or older can collect €2.5K if they put the pile of rust out of its misery, and buy a new one.

In the beginning, the program was ridiculed. It’s not going to work, said many, owners of clunkers won’t buy new. The Green Party said it’s “a joke.” Quickly, the mood changed.

Polk Germany prognosticated that the program would result in seven percent more sales than in 2008, that’s 200K units. A few days later, a new study said 1.2m people would buy a new car because of the Abwrackprämie. Too good to be true, given that barely 3m new cars were sold in 2008, with gruesome losses in Q4 08 and an awful January.

This strikes me as a pretty good idea. For the most part, old cars get worse mileage, have worse emissions, and are less safe than new cars. It’s a simple idea but one that could be of huge benefit to the car industry, and have some environmental benefits as well. Sounds like stimulus to me.

The modern developer résumé
3

The modern developer résumé

This job posting led me to a thought — are people getting jobs based solely on their Github profile? If not, how long will it be before people do find jobs that way?

Maybe it’ll take a Github profile and a blog. If you know what someone has written about their work over a long period of time, and you know what kind of code they’re producing, what else is left? Interviewing for team fit, perhaps, but such a record certainly takes a lot of guesswork it seems.