Technical Bankruptcy

May 23, 2008

The mess I have inherited here at Ideal is technically insolvent.
Dodge Charger

I knew a guy a named Bill few years back who had a brand new Dodge Charger SRT-8, which he paid $850/mo for. He loved that car. He cleaned it meticulously (the only thing he was meticulous about), he drove it incessantly, and he became so attached to it that he eventually lost it.

After adding insurance, gas, and other bits and pieces he sunk into the car monthly, he was throwing more than half his income away. When it became increasingly difficult to pay his rent and other bills, he just couldn’t trim the budget – he loved the car so much that he started eating into his credit to make ends meet.

The situation became worse when he started opening new credit accounts as the others reached their limits. The minimum payments on his 9 separate cards added up to more than he paid for is car every month. When the credit ran out, he was sunk. Stuck with debt that was over half his annual income, with living expenses outpacing earnings, he has to choose between his roof and his car.

By the time he parted with his beloved car, it was too late. He still had to have a vehicle to get to work, so net monthly savings was only $600, while his new credit bills were over $2,000 a month.

This is insolvency: having greater debt than assets. Bill had more bills every month than he could pay, and it was because he didn’t spend wisely. Luckily for Bill, in America we have bankruptcy instead of debtor’s prison.

Behind Bars

Coined by Ward Cunningham, and introduced to me by Steve McConnell, Technical Debt refers to borrowing time on software projects in exchange for quality. Any time we want to add a feature to a piece of software, we are faced with a choice:

“…one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.” – Martin Fowler

Briefly, Technical Debt is similar to in character to financial debt:

  • You have to pay it back with interest. When you cut a corner, you eventually have to go back and implement the feature correctly. By the time you do, there are other parts of the project that are dependent on the corner you cut, so it will actually be more difficult to write correctly. Prior to that, changes you make to other parts of the software will be made more difficult by your poor design. This is the interest.
  • Long and Short Term. Short term debt, much like a credit card, is often unplanned, high interest, and should be paid off quickly. In other cases, you can borrow strategically with a plan to pay it back over time. This is like writing a quick and dirty prototype in order to be first to market, then using the financial momentum to rewrite.

If there was a technical debtor’s prison, Ideal would be behind bars. Poor management and poor programming have piled loan on top of loan, and now, like Bill, our interest payments are greater than our income – the principle is growing, and we don’t have the assets to pay it all back. Practically what this means is that our software products have grown out of control, and our programmers time is consumed with a growing list of critical failures and bugs streaming in from increasingly irate customers. We don’t have time to fix the outstanding issues, never mind improve the software!

Prison Break

Prison Break!

I realized that the situation was not salvageable about a week after I started work. That’s when I began quietly gathering requirements, and creating a completely new architecture. This is dangerous territory. I’m flying against the prevailing wisdom of our field by doing a potentially ill-advised rewrite, and I’m doing it under the noses of the guys who wrote the bankrupt software.
I thought very carefully about the rewrite, being aware of the reasons not to do one: that was technical decision best left to another article. The political issues, however, are human, not technical. The fact is that if a new person comes into a group and says “Hey everyone, the work you have been doing for the last few years is awful, and I’m going to redo it,” he will be universally despised.

What I chose to do instead was listen to the guys, and find out what they thought. They had many pain points as they bore their onerous technical burden from one dismal release to the next. Each time one mentioned something that sucked up their time, I was quick with: “Wow, is there any way to make that better for you?”

As an aside, I knew this question wouldn’t get a good answer. If these guys were capable of planning easily maintainable code and articulating solutions, Ideal wouldn’t be in this situation. Invariably, they say “I don’t know, I can’t think of anything…”

That was my opportunity to offer a suggestion like “Well, what if we could [idea here], and that way you wouldn’t have to do this anymore, and you’d have more time to do [fun activity]?” When I said something like this, I was met with cautious enthusiasm like “That would be great… if it ever happened.”

“Let me work on that for you,” I’d say. Often my off the cuff idea had already been implemented in the new architecture. For example, we have user permissions that control access to the functionality in our software. Right now those permissions are hard coded, so that to change the permissions a developer has to change code and recompile. The better way to do this is to store it all in a database, accessible through an admin interface so our implementations people can do it without bothering the developers. This was planned well before a developer on the team lamented the situation, and I took the opportunity to get him excited about the possibility of the admin interface.

Champion of the People

The result is that the new software is different things to different people. Each person has a unique set of expectations that I’ve tailored to them in particular. Some people are looking forward to automated licensing, others user permissions. Other people are looking forward to whole thing being packaged so that it can be installed with one mouse click instead of arcane voodoo they have to work now to get systems running. Everyone feels like I’m working on something just for them, that will be designed to solve all of their problems specifically.

By the time I’m finished, it will be the software package Ideal needs to move forward instead of sinking, and everyone will be thrilled that I’ve built something just for them. Undermine peoples’ natural territorial feelings by carefully soliciting an invitation into their territory.

Advertisements

One Response to “Technical Bankruptcy”


  1. […] to Perform Miracles June 2, 2008 As I discussed previously, Ideal needs a complete overhaul of its technology systems. There is an unintended consequence of […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: