The Proper Care and Feeding of Programmers

IT'S MONDAY MORNING and a team is holding its weekly status meeting. Although they don’t know it, they're about to demonstrate three developer realities that managers often do not understand. Let's observe them in their natural habitat to see if we can learn anything.

Programmers Need To Fail To Succeed
Jay, one of the programmers, is the first to speak. He tells everyone he's behind in developing the new security subsystem. He spent last week investigating a third-party product that might have been a tremendous shortcut if it had worked. But, it didn't, and now he's a couple of days behind. Terry, the manager, her face red with anger, asks Jay why he spent time investigating a third party product when that wasn't on the schedule.

Terry Just Made A Mistake.

Often, on the path to a finished design or finished code, a programmer will take a detour through a flawed implementation. Managers often view these detours as mistakes; programmers view them as necessary steps toward the right solution. There is rarely one obvious solution to a programming assignment. To find the appropriate solution, programmers need the latitude to occasionally try solutions that do not work. When a solution doesn’t work, the programmer learns from the experience and tries the next solution that his knowledge and newly gained experience tell him is best. If the project is already behind schedule or if, as the project manager, you've become overly focused on marking tasks as complete on the schedule, this can be disconcerting.

A few years ago programmers even introduced a new word, refactoring, to refer to one type of detour through an unsatisfactory final solution. Refactoring refers to changing the structure but not the behavior of a piece of code. Programmers refactor when they have a piece of code working but do not like how the code is written or organized. By refactoring that code, they are often changing the underlying design (for example, introducing a class here or removing one there) but are creating code that will be more maintainable over the life of the project.

Programmers Like Challenges
During the status meeting, Terry questions Susan, another programmer, about why she's behind developing the five new screens. Susan acknowledges that she's behind but tells Terry that she's developing a user interface framework that will make it easier to develop all future screens. Susan says that, while she's behind now, she's confident that the new framework will help her catch up—as soon as she works out all the bugs.

Susan Just Demonstrated What Happens When Programmers Don't Feel Challenged.

Good programmers like challenging assignments. They enjoy being pushed to do something they haven't done before, to use a technology they haven't used before, or to do something better, faster, or smaller than anyone else has ever done. If a programmer isn't challenged by the assignment you give her, she will often find ways of making it challenging. Susan was assigned to write the user interface code for five new screens. But, instead of simply coding those screens, she coded a user interface framework that allows screens to be specified declaratively in an XML file. To test her framework and to deliver the screens, she wrote the XML file that defined the five new screens within her framework.

Of course, introducing a framework like this could be a good idea. The problem here, however, is that the decision to introduce the framework was made by one programmer and was introduced for the purpose of making her work more challenging and, therefore, more fun. This expansion of scope was only possible because