Years ago, I started noticing people doing the wrong things at work. I first saw this while working in a computer lab. We worked with the leading edge computer hardware, software, and peripherals -- the best toys available. The problem was that people were looking for problems so they could buy the solutions. These people were wonderful problem solvers and spent their time doing that. They were comfortable solving problems rather than defining them; doing versus thinking. The trouble was, they often solved the wrong problems.
That experience caused me to think about the habits I had seen in programmers. Most programmers spent inordinate percentages of time coding. They, and I, would start typing code before hearing a complete statement of the problem. I remembered all the admonitions in college to "fully understand the problem before starting programming." Those lectures, however, were taught at a university where we were limited to one run of our program per day. We were now coding and running programs all day. The feedback from coding was so immediate that surely we were supposed to code like hell all day.
We were computer programmers and so that is what we did -- program. Sometimes we called ourselves software engineers. That brought up thoughts of design before coding. We dismissed those thoughts because we only used the "software engineer" term while trying to justify higher pay.
As I moved on in my career (no longer allowed to program), I saw a similar trend in other jobs. Different people approached the same job in vastly different ways. One person would replace another in the same job, but spend most of their time doing something completely different from their predecessor. I found myself doing the same. I changed the job to suit me, instead of the other way around. Nothing had changed in the job except the person doing it.
It took me years to fit all this into a pattern of behavior. The pattern is that we all drift to the comfortable and familiar. The problem solvers I worked with sped through problem analysis to reach problem solving and then quit before implementing a solution. The programmers rushed through analysis and design and skimped on testing so they could spend seven of the eight hours a day coding. Everyone adjusted their job to themselves so they could do what they liked best.
Managers and team leaders must watch out for this drift to the comfort zone. We convince ourselves that we are "tailoring a process to a project" or some other convenient phrase. What we are doing is what we like to do. As professionals, we must do the right thing, even when it feels wrong or uncomfortable. Analysis is necessary, not simply a step to check off before we do the real work of coding. Peer reviews are necessary, not just something to check off to qualify for CMM or ISO or whatever.
It is best to have people who like and are good at analysis do analysis while good, happy designers design, and so on with programming, testing, QA, etc. When those people aren't available, have less capable and satisfied people do those tasks anyway. We want to have people be happy at work, but it is work, and we do need to send good products out the door to keep the doors open. That is our challenge. Who knows, if we are successful enough, maybe people will learn to be comfortable outside their old comfort zones.
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He is the author of *The Software Project Manager's Handbook, Principles that Work at Work* (IEEE Computer Society, 1998). Mr. Phillips has a Ph.D. in electrical and computer engineering from Louisiana State University. He can be reached at d.phillips@computer.org.