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.
Old Habits Die Hard
When learning a new technology, ask yourself if you're projecting too much of the old attitudes and approaches onto it. For instance, 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#. 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--and the hardest part--is to realize that you're using an outdated approach. The next hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost, and one doesn't discard them lightly. It takes awareness, conscious effort, and hard work.
Taking the time to transition completely to the new environment can help. 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. It's easier to form new associations and new habits when there's less baggage from the old habits lying around.
When learning something new, unlearn the old that it replaces. After all, there's a lot more to a car than just a "horseless carriage."
