27 May 2006

What's Temporary is Permanent

When you code you often have to make a decision to either hack together a temporary fix or design a robust solution. It's often easy to do the temporary fix, because for example: 1. It isn't critical code 2. Time is of the essence, "We need to ship now!" 3. There is high degree of confidence that it be visited again after we ship and be fixed up. 4. Surely, this code will not last that long. I'm sure there are other good reasons to "git 'er done!" and get things working, but more often than not, what isn't critical code, becomes critical. What was going to be revisited and re-factored, now works, and in priority queues of life, "if it ain't broke, why fix it?" Lastly, rarely does one "come this way again" just to tidy up. The moments spent in front of a block of code are more fleeting than you think. This may not be news to developers more experienced than I, but as much as I hate to admit it, what was once temporary, almost always becomes permanent. There will come someone this way again, but not to tidy up, more often than not, they come to build upon your work and in the best of object oriented abstraction, your implementation and all it's bandages, bailing wire and duct tape often remain hidden. Hidden that is, until they break in catastrophe. All this reminded me of a poem I recently heard by Will Allen Dromgoole:

The Bridge Builder An old man, going a lone highway, Came, at the evening, cold and gray, To a chasm, vast, and deep, and wide, Through which was flowing a sullen tide. The old man crossed in the twilight dim; The sullen stream had no fears for him; But he turned, when safe on the other side, And built a bridge to span the tide. "Old man," said a fellow pilgrim, near, "You are wasting strength with building here; Your journey will end with the ending day; You never again must pass this way; You have crossed the chasm, deep and wide- Why build you a bridge at the eventide?" The builder lifted his old gray head: "Good friend, in the path I have come," he said, "There followeth after me today, A youth, whose feet must pass this way. This chasm, that has been naught to me, To that fair-haired youth may a pitfall be. He, too, must cross in the twilight dim; Good friend, I am building the bridge for him."
When you write code, consider what it might look like to a new hire 10 years from now. Make it something that can be built upon, because whether your like it or not, it will have a long, long life. Note 1: The same could probably be said for UI design as well, but that's probably worth another post entirely. Note 2: The picture above is of the the Eads Bridge built in 1874 is the oldest bridge over the Mississippi River, and the world's first steel arch bridge.


Mahesh said...

Hello David,

How are you doing?

So the beta of Office 2007 has been released to the public.

How about the next version of MS Office for Mac? Will the beta be released for download?


Anonymous said...


You really make a good point. It is so tempting to do the "quick and dirty" fix, and I've certainly done this enough times myself (and had them fall apart later on ;)). Even more often, I've been tasked with fixes other people's hacks. The sad thing is that it often wouldn't take that much longer to implement a more robust fix.

I love the poem. Think I'll send it to the other developers on my team.

Thanks for all your great posts.


Lyne said...

I hope everyone on the team reads this post. Thanks David, well said...

James Lincoln Warren said...

Back in the day, we used to call the result of too many convenient software fixes that became permanent "spaghetti code", in reference to all of the jump instructions.

Another result of solving problems with the digital equicalent of chewing gum and bailing wire is that applications get bloated, requiring far more resources to load than they actually use. A classic example of this was Microsoft Word 6, which did nothing more 0r better than WordPerfect 5.2, but required eight times as much memory to run. In those days memory wasn't cheap like it is now.

mem said...

Good post. Code is a lot like tax law: once it's compiled, it's awfully hard to get rid of. (Case in point is the recently-repealed phone tax used to support the Spanish-American War.)

Arun Sadhashivan said...

I learned the poem when I was in primary school. I was 9 years old and it was in my English Rapid Reader book. It's nice to see the poem reproduced here.

Any idea who wrote it?

Warm regards,

indy said...

As I recall, a coworker of mine once wrote a localization string editor. A year or less later, the coworker had to write a new string editor. Code can be very short lived, especially when technologies change.