Lost in the heat of an engaging programming assignment, sweet temptation can seduce us into coding a quick and dirty hack rather than crafting a more elegant solution. This article suggests, first by analogy, and then in more concrete terms, the possibility that sometimes it might be best to succumb to the allure of the hack.
Let’s begin by setting up an analogy. You’re in the market for a new car. You weigh the pros and cons of a few models, make your decision, and then go to the dealership to buy it. Without going into too much detail, you have two ways to pay for your new wheels: you either pay for it up front (lucky you!), or you take out a loan to help pay for it (I’m ignoring leases in this argument, since they can be viewed as loans with a final balloon payment).
If you go with the loan , then you are going to be assuming some financial debt. You have to make regular payments to the bank or financial institution to pay off the principal and pay the interest on the loan. Obviously, at the end of the day you will pay more overall for the loan than you would have if you’d just slapped down the cash at the outset. But depending on your situation, the loan can still be an attractive alternative despite the extra cost.
OK, bear that in mind, and consider this. You have some software to write; maybe some extra functionality for an existing system. You recognize that you have two choices.
- You can write it "properly"; that is, design it using the proper agile methodology, write good test cases, refactor code smells into oblivion, ensure that it is flexible and can accommodate some possible extensions, etc
- Or you can write a quick and inflexible hack that gets the immediate job done.
However, you also realize that if you were to do the latter, there will come a day when you will have to add some extra functionality to your quick and dirty module. At that time, you will almost inevitably encounter several problems related to the inflexibility of the hack. You will then have to do some, or maybe all, of the work that you managed to avoid by doing the hack in the first place.
Ward Cunningham called this idea "technical debt" to mirror the monetary analogue. If you do the hack work, you are essentially reaping the rewards of getting the job done quickly and then "paying interest" later on in the form of the additional work needed to extend the functionality. You are going to assume the technical debt; hack work is not debt-free.
If you want to pay for it all up front, then you’d take the time to design and write the software using test-driven principles. Of course, just as in the case where you buy the car outright, you have to have the resources to do so.
So sometimes it will make sense to write the code properly (pay up front) and sometimes (horrors!) it can make sense to write a quick and dirty hack (pay a little now, pay interest in the future). Your job as a software developer is to recognize the situations where it does make sense to incur technical debt rather than paying up front.
As an analogy, don’t take it too far. Unlike the monetary situation where you can easily quantify the difference between paying up front and assuming interest payments, technical debt must be analyzed more qualitatively. Who knows how much more effort is expended in maintenance incurred due to a hack versus elegantly designed code?
As I said, use your judgment, but sometimes it can make sense to write a quick hack.