12.1. Reuse = Laziness

I'm not really sure whether it is a character flaw or a skill, but I have a tendency to code some routines twice. The first time is to solve the particular problem at hand; the second time is so that I have a generic solution if the problem crops up somewhere else. Sometimes it does and sometimes it doesn't, but it is nice to be able to accept an assignment and have at least part of the solution coded. It is also a great way to make sure that there is always time to read User Friendly.

Unfortunately, when I started my career, this wasn't the case, mostly because I encountered managers who believed in the puritan work ethic: Work constantly until you die, or quit before the age of 33, a burnt-out husk. Basically, the more lines of code, the better, although they sometimes cloaked their philosophy behind the words "I need it so that everyone can understand it" or avoid "mad scientist stuff." However, during the years, this type of manager has largely either died off or retired. I suppose that, on some level, I will miss them, in much the same way as a headache that has gone away. Yes, I will sorely miss the threats of nonpayment for reusing code to create new applications.

"Hello, my name is Ed. I reuse code to death and I am not lazy!"

12.1.1. Paid by the Line

Several years ago, as a consultant, I was assigned the responsibility to write client-side JavaScript whose sole purpose was to speed up the client's website. The problem was that they had a vision of what they wanted, but they didn't quite know how to implement it. For example, let's say that a web page consisted of 20 rows in an HTML table, each of which had a select created from a database query, and that each select had the same options. They saw nothing wrong with executing the same query 20 times and using VBScript 20 times to create the 20 selects. Oh, there were two other things: With the exception of looping through the results of the query, there were no loops, and there wasn't even a function that was called 20 times. The code was one straight run. Because it had been written by the lead developer only about six months before and I was only a consultant, I never asked the burning question: Why?

It didn't take me more than a couple of days to figure out the answer. In fact, all it took was one glance at their JavaScript library. The entire library consisted of a single function whose purpose was to determine whether a parameter was numeric, not that it was used anywhere. It was almost like I had stepped through a rift in the fabric of space-time and found myself in an alternate reality. The more I examined the site, the more I kept looking around expecting to see Rod Serling. To give you an idea, it was after Y2K and they were still using HTML FONT tags. There was not a single example of Cascading Style Sheets anywhere. The word deprecated didn't exist in their world.

There were classic ASP pages that were in excess of 30,000 lines of mixed script and HTML. I was a stranger in a strange land where developers were paid by the line. It was a new application, not yet in production, so it couldn't have been maintained into incomprehensibility. What else could explain the way that things were?

12.1.2. Paid by the Page

Fortunately, I was paid by the pagealright, actually, it was by the hour, but I had a limited number of hours to produce each page. Couple this with the fact that I'm a hunt-and-peck typist, and you'll quickly understand why I'm a big believer in code reuse. The odd thing was that, with one exception, nobody ever noticed that code was being reused left and right.

On one of my last consulting assignments I met an intern who was fresh out of school yet was one of the sharpest developers I ever met. After working together for about six months, he asked me why it seemed that whenever possible I wrote reusable code that often used reusable code that I had written previously. There was only one way to answer: "I like writing tools to make tools."

A simple enough phrase, "tools to make tools," but what does it mean?

Ask me what I mean, and I'll say that it means that there is an underlying architecture that can be built upon. But to me personally, it goes much deeper than that. Take a moment and look around you; what do you see? You're surrounded by toolstools that shelter us, tools that entertain us, tools that preserve our images and thoughts beyond our individual lifespan.

Where did these tools that have become so important come from? Somebody created them, another person used them, and yet another person improved them. In essence, the Internet is merely an improvement of a cave painting taken to the nth degree. There's a long history of our species creating "tools to make tools." Therefore, it is only natural to create tools, share those tools, every once in a while wonder who will improve them, and lament the fact that you can't get a good mastodon sandwich anymore.