Thinking for a Change

The incredible shrinking program

I just don’t seem to learn, do I?

A classic experiment

Years ago, during a course on software engineering, the professor described a classic experiment: several programmers were given the same application to write. Each was asked to optimize one non-functional requirement: speed of implementation, speed of application, size of application, readability of the code, run-time memory use… Each developer was able to optimize what was asked of them, at the expense of one or more of the other qualities. No surprise there. TANSTAAFL.

I decided to perform this experiment on myself.

At the time, I was writing a hypertext help compiler and viewer, so that I could always pop up the programming reference documentation I needed while programming. The first useable version of the executable was about 20K (yes 20480 bytes) long. It might be fun to see how long I could keep the application at that size. As this was a resident application, the smaller the program was, the more memory was available for the IDE, compiler, debugger and the application I was developing.

A simple game with the expected results

So, I played a game with the following simple rules:

1. Get the most important feature from the feature list and implement it, until it works
2. If the application is larger than 20K, rework it until it’s smaller than 20K. All the features must still work!
3. Again…

The results were as expected: I managed to keep the application under 20K. This came at the cost of implementation time: sometimes it took a lot of ingenuity and work to squeeze the code back into that 20K. I had to find duplicated stuff, places where I could simplify the code, error handling I could remove because I had made it impossible for common user mistakes to happen…

And some unexpected results

I expected code readability to suffer: I might have to abandon my object-based C writing style, replace C code with more efficient assembler or use complicated tricks to keep the application small. I never needed to do that. If anything the code became more readable…

There were some unexpected side effects. In my experience, the longer you worked on a program, the more features you added, the more difficult it was to add (and debug!) new features. This program was really weird: it kept getting easier to add new features. Wow! That hadn’t happened to me until then and wouldn’t happen again for a long time after that.

This was the first program where I and my users (the application was released as shareware by then) ran out of ideas before my programming ran out of steam.

And what have we learned from this?

I stopped playing with limited home computers and started to work on real men’s computers: Unix workstations. I stopped making my programs small. There was no need: there was plenty of memory (megabytes!) in those machines. I was taught that it was cheaper to upgrade memory than to spend expensive programmer time.

And things were back to normal: with each new feature, it became more difficult to add another one. That’s how it’s supposed to be, isn’t it?

When I give a talk on Agile or Extreme Programming, there are two stereotypical answers I get from the participants:

• That won’t work (where I work).
• That’s just common sense. I’ve been doing that for years.

The first reaction is an ideal opening to ask the question: “You’re right. But… what’s the worst thing that’s holding you back?” That way you might discover their constraint.The second answer is a bit more tricky to deal with. Often, the answer indicates a lack of understanding of Agile software development: “I’ve been working without specs all my life. I was XP when you were still in diapers, son!“. If not, get their stories out and learn about their successes and failures.

I was like that, until a few years ago. Since then I’ve learned two things:

• It has worked everywhere I worked for the past 5 years. In fact, it’s the only thing I’ve seen work in that time.
• If it’s common sense, I must not have much common sense. Or any sense at all. I did things consistently as I had been taught them and was consistently unhappy with the results. Not that this made me change the way I worked; I just tried harder. Someday, it will work…

It’s not that I haven’t had many opportunities to learn. I just missed them all. I was probably trying too hard to notice the obvious solutions staring me right in the face.

So, let me tell you about some of these learning opportunities I missed…