7   Know When to Unlearn

“That’s the way you’ve always done it, and with good reason. It usually works for you just fine. The ways you learned when you first started are clearly the best ways. Not much has changed since then, really.”

One of the foundations of agility is coping with change. Given that change is so constant and pervasive, does it make any sense to keep applying the same techniques and tools you’ve always used?

No, not really. We’ve spoken at length in this chapter about learning new technologies and approaches, but remember that you’ll need to do some unlearning as well.

As technology marches on, things that used to be of paramount importance fall by the wayside. Not only aren’t they useful anymore, they can actually harm your effectiveness. When Andy was first programming, memory overlays were a big deal. You often couldn’t fit the whole program in main memory (48KB or so) at a time, so you had to split your program into chunks. When one chunk was swapped in, some chunk had to be swapped out, and you couldn’t call functions on one chunk from the other. That very real constraint affects your design and coding techniques dramatically.

Back in the old days (when you could write about the artist known as Prince without resorting to a bitmap), you had to spend a lot of effort wringing extra cycles out of the processor by hand-tuning the assembly language output of the compiler. Can you picture yourself doing that in the context of some JavaScript or piece of J2EE code?

For most business applications, the technology has changed dramatically from the days of limited memory footprints, manual overlays, and hand-tuned assembly language.^[8] But we’ve seen more than a few developers who never unlearned their old habits (and Prince, by the way, is once again known just as Prince).

Andy was once shown a piece of code that contained a single large for loop, written in C. The code inside the loop went on for sixty printed pages. The author “didn’t trust” compiler optimizations and decided on doing loop unrolling and other tricks himself, by hand. Best of luck maintaining that mess.

Once upon a time, that might have been an acceptable trade-off. But not now. Machines and CPU cycles used to be the expensive part; now they are commodity. Developer time is now the scarce—and expensive—resource.

And that fact is slowly but surely dawning on people. We’ve seen ten-man-year J2EE projects go down in flames, only to be replaced with a month-long hack in PHP that delivers most of the features. Growing interest in languages such as PHP and web frameworks like Ruby on Rails  (see Agile Web Development with Rails, 4th Edition [RTH11]) show that developers are catching on that the old ways might not be cutting it anymore.

But unlearning can be hard. Many a team has floundered because management refused to spend $500 on a build machine, preferring instead to waste tens of thousands of dollars of programmers’ time chasing down problems that shouldn’t have even come up. That would have been the right answer when machines cost $500,000, but it’s not the right answer now.

When learning a new technology, ask yourself whether you’re projecting too much of the old attitudes and approaches onto the new. Learning to program in an object-oriented language is fundamentally different from programming in a procedural language. It’s pretty easy to spot someone writing C code in Java, for instance, or VB in C# (or Fortran in anything). When that happens, you’re losing the very advantage you hoped to gain by moving to the new technology.

Old habits are hard to break and even harder to notice. The first step to unlearning is to realize that you’re using an outdated approach. That’s the hardest part. The other hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost over many years. One doesn’t discard them lightly.

And it’s not that you really want to discard them completely, either. The previous memory overlay example is just a special case of manually maintaining a working set of items from a larger cache. The technique hasn’t gone away, although that implementation of it has. You don’t want to drill into the brain and snip all those dendrites off. Instead, you want to use older knowledge in context. Reinvent it and reuse it where applicable, but make sure you don’t drag along old habits just out of, well, habit.

It can help if you take care to transition completely to the new environment as much as possible. For instance, when learning a new programming language, use the new IDE that comes with it instead of the plug-in that works with your old IDE. Write a completely different kind of application from the kind you usually write. Don’t use your old language tools at all while you’re transitioning. It’s easier to form new associations and new habits when you have less baggage from the old habits lying around.

Learn the new; unlearn the old. When learning a new technology, unlearn any old habits that might hold you back. After all, there’s much more to a car than just a horseless carriage.

What It Feels Like

New technology feels a little scary. It feels like you have a lot to learn—and you do. You can use your existing skills and habits as a base, not as a crutch.

Keeping Your Balance

• The only difference between a rut and a grave is their dimensions. Keeping old habits past their expiration date is hazardous to your career.

• Don’t forget the old habits completely, but use them only when using the appropriate related technology.

• Take special note of familiar idiosyncrasies in the languages you’ve worked with, and learn how these are similar or different in newer languages or versions.