Starting to Payback the Design Debt

For the past few months, I have been working on an extensive project
to “internationalize” one of our flagship products. This product is
slated to be released to the Canadian market by the end of this year.
Being a very old web application (going on five years now), this
product, at the time, exhibited some of the best qualities of what is
now known as AJAX: some form of XML handshaking, asynchronous
communication, and good responsiveness.

But, with a lot of legacy software, this product is suffering from a
very large design debt. I first heard this term from an
associate at work, and I am glad that I can associate what I been
feeling over the past couple of year to actual words. Essentially, a
design debt is a metaphor that describes the cost software incurs
when hurried (or outright bad) decisions are made because of time,
money, or other constraints, sacrificing the overall quality of a
design in the long run. Like any other debt, someone has to pay the
debt down.

Well, I am paying a lot of design debt right now. I have been
refactoring a lot of code over the last month or so. Because code is
shared across most of our applications in our product line, the risk
is somewhat high. Luckily, I had five years to think about it. Just
as I start to pay the debt down, it starts to go back up. Once again,
time constraints forced others to make some tough decisions in other
parts of the application.

I now come to the realization that we cannot completely dig ourselves
out of design debt without a significant change in our development
lifestyle. Just like a credit card with a high interest rate, we seem
to get trapped by the situation, feel like there is nothing we can do
about it, and eventually give up. Companies with a large accumulation
of design debt eventually will declare “design bankrupcy”. The toss
out the legacy application altogether and start fresh. For me, it’s
happening right now.

Since my employer uses only Microsoft technologies, design bankrupcy
was inevitable. ASP and COM is being replaced with .NET. Visual Basic
6.0, the language of which most of the backend code for products is
created, is now officially unsupported. A significant amount of code
was created in a proprietary language, and now we are scurrying to
create our next-generation versions of our product line using the
latest “killer framework”. No doubt that more design debt is
incurring, especially as Microsoft releases newer versions of their
.NET framework. So, it’s a vicious and endless cycle that needs to
be understood and controlled.



%d bloggers like this: