The Joy of Unlearning


There's more to a car than just a horseless carriage; you can't approach new technology with old habits. In this column, Andy Hunt explains more about the unlearning process and how rewiring your brain isn't as hard as you might think it is.

One of the foundations of Agile development is coping with change. But despite change being so constant and pervasive, you may find yourself applying the same old techniques and approaches you've always used. As important as learning is, remember that you'll need to do some unlearning along the way as well.

As technology advances, once important things may fall by the wayside. Not only are they no longer useful, they can actually harm your effectiveness. When I began programming, memory overlays were a big deal. You often couldn't fit the whole program in main memory (48K or so) at once, so you had to split your program into chunks. When one chunk was swapped in, another chunk had to be swapped out, and you couldn't call functions in one chunk from the other. That sort of constraint dramatically affects your design and coding techniques.

Not long ago, much effort was spent wringing extra cycles out of the processor by hand-tuning the assembly language output of the compiler. Think of that in the context of writing some JavaScript or a piece of J2EE code.
For most business applications, the technology has changed extensively from the days of limited memory footprints, manual overlays, and hand-tuned assembly language—although this may still be the case in embedded systems development—but some developers never unlearn their old habits.

Once Upon a Time
I 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 to do loop unrolling and other "tricks," by hand. Once upon a time, that might have been an acceptable tradeoff. Machines and CPU cycles were expensive, but now they are common. Developer time has become 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 necessary features. Growing interest in languages like PHP and Web frameworks like Ruby on Rails shows that developers are realizing that the old ways may not cut it anymore.

But unlearning can be hard—corporately as well as individually. Many a team has floundered because the management refused to spend $500 on a build machine, choosing instead to waste tens of thousands of dollars on programmers' time chasing down problems that shouldn't have even come up. That may have been the right answer years ago, but not now.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!