How to Fail at Software Development

13. Does everybody know exactly what is trying to be accomplished?

Score at least 1 if one or two team members become easily confused. If you have a couple of members that occasionally, right in the middle of the work day, find themselves bewildered, you will have to discount the work they are going to produce. There are two types of permanently confused people. One of them takes up a lot of time going around asking other people questions on the level of, “Where does my password go after I enter it?” and “If the compiler compiles the source code, and it can see all the errors, why can’t it fix them?” The other type tries to tough his way through and occasionally comes wandering out of the bushes proud of something that is completely useless—something that could even cause harm if it were to be connected to the rest of the system. About all you can do is hope they get lost one day coming back from the rest room so you won’t have to deal with them any more.

Score at least 2 if most of the team has a pretty good idea of what’s going on, but a lot of them don’t. The overall goal may be a bit out of focus around the edges, but that could be because the specification is vague and the project manager has decided to leave it that way for his own purpose. Or maybe the project manager is one of those wandering around like a deer caught in the headlights. You be the judge—the more sever the case, the higher the score.

Score at least 3 if the split is close to half and half. Half the people have no idea why the project exists and the other half spend most of their time trying to explain things or repair what the first half has done. This kind of project is a terrible thing to watch. Have you ever watched a bird pull out all of its own feathers?

Score at least 4 if you have one power programmer who knows everything and everybody is asking him questions about what they should do. The super whiz-bang is usually a being that knows everything and is highly revered by management. His explanations always leave the listener with more questions than answers. When asked how to proceed, he will say something like, “If you compile all the source code in this directory it will give you a program that will scan the tables and pull out what you want to know. It’s the standard Mongolian form of rapid development with the added benefit of automatic text editing.” Then he walks away. You have no idea what the hell he was talking about, but you have some sort of vague notion that you should compile the program in the directory he named. You do that, and then go back and ask another question. That’s really all you can do. This is the process known as rinse-and-repeat, which you will find on every bottle of shampoo.

Score at least 5 if no one around you has any idea of what you are all really doing. All attempts to discover the project’s purpose in life fail to get an answer. It’s like that old joke, “We may be lost, but we’re making good time.” Everybody is working frantically to build some part of something, but the large picture is vague. Think of a jigsaw puzzle where the box with the picture can’t be found. If you dig too deep into this situation you will get explanations like, “This system will process data for a business model that we haven’t implemented yet,” or “They haven’t built the hardware device yet, but we will be able to talk to it when they get it working.”

Chapter 4 of How to Fail at Software Developmenet explains some of the techniques used to recruit the clueless.