When facing a new situation, we have a very strong tendency to retreat to what we know, and convince ourselves that the approaches we have used in the past will always work in the future. It’s hardly surprising; developing new skills takes time, and we take pride in how well we can do them. This is played for laughs in the 1967 production of The Producers when the success-challenged director, Roger de Bris grumbles about his history with musicals, and leaps at the chance to do a serious play about the Nazis:
Dopey show-girls in gooey gowns. Two-three-kick-turn! Turn-turn-kick-turn! It’s enough to make you throw up! At last a chance to do straight drama! To deal with conflict, with inner truth. Roger De Bris presents history. Of course, I think we should add a little music. That whole third act has got to go. They’re losing the war. It’s too depressing. We’ll have to put something in there.
Aaahghhh! I see it! A line of beautiful girls, dressed as Storm Troopers, black patent leather boots, all marching together… Two-three-kick-turn! Turn-turn-kick-turn!
It can be hard to recognize when they don’t apply to new situations. Being told that we must do something new can often feel like an attack, with the implication that we’re not very good at our jobs. This has led to the observation that change only happens when the pain of not changing finally exceeds the pain of changing.
But change is often necessary. Software development is still relatively new compared with traditional engineering, and the pace of innovation is astonishing. Conferences are full of presentations on new APIs and new tools, and developers rush to try them. What they tend not to change as easily, though, is the way they do their work.
Again, this is not surprising. Taking on a new task is not a negative reflection on anyone; if anything, it is a sign of success to be able to tackle new projects. Pride and habit, though, lead developers to apply their old approaches to them, just as Roger De Bris does in the above quote.
Over the years, leading practitioners have developed better ways to build and manage software projects, from structured design to object-oriented development, to test-driven development. These approaches, however, have been relatively slow to catch on. A few years ago, for example, one prominent head of a consulting company estimated that only about one developer in twenty had adopted regular unit testing and refactoring – well over a decade since they had been demonstrated to be effective.
It isn’t that programmers are not aware of these innovations, so much as they represented a clear change in approach, and imply that the way those developers have been working is not good enough, and that those who have mastered them could be passing them by. The usual first response is to deny that they have value, or that they represent something new.
When the changes do not vanish, they next step is often to try to co-opt the terminology. Thus, we have people saying that are being agile when they skip design documents and jump right into coding, or calling any change to existing code, refactoring. This phenomenon is sometimes knows as being buzzword compliant and suggests that those using this language are now following the indicated practices.
Names, one might image, shouldn’t matter all that much, and if it makes people happy to adopt the language, how can that be a problem? But it is a problem, in that it is an obstacle to improvement. This pollution of the namespace makes it hard to explain why changes are even necessary. How, for example, do you make a case that a team would be better off adopting unit testing, when they are already calling their slow functional tests, unit tests?
One thing programmers should have learned long ago is that name selection matters. Calling a method checkFlag simply does not convey the same information as isLoggingEnabled. Given that software is heart the communication of ideas, both from programmer to computer and between programmers, being careful with terminology can often spell the difference between success and failure, and embracing change is an essential part of achieving success.