Â© 2001 Mark Manduke
In teaching software process improvement and discipline, I sometimes encounter a phenomenon I describe as “The Tsunami of Whining.” (Tsunami is a Japanese word for “Tidal Wave.”) Some students complain about certain issues and often do so in a rather demonstrative fashion. They offer excuses or what they perceive to be valid reasons why “this stuff doesn’t apply to me.” The complaints often begin with something like, “Awww mannn!” or “But you don’t understand!” I’m sure that you’ve heard at least some of them, too. Here are a few of my favorite whines, a list that is expected to grow over time:
Whine #1:”You want us to document stuff? This is going to slow us down! What’s the absolute minimum that we need to write down?”
First of all, let’s assume that you are working in a group and for an organization. If you work alone, developing and maintaining your own products throughout their productive life, you will generate your own techniques to survive (or not, as the case may be!). However, most software managers and developers work in groups and share the responsibility for producing software in a way that enables the product to be shared and understood. Unfortunately, since software is “invisible” the only way to tell how a software product will be implemented, what it looks like, or how it is expected to operate is through documentation. When thinking about how much to write down, consider two things: Learning and Honesty.
Learning: You will make mistakes developing software. That’s fine, no one is perfect and software is one of the most intellectually demanding exercises that human beings do on such a large scale. But when your organization repeats the same mistakes over and over, shame on you! You need to be writing down enough “stuff” so that you (and others in your organization) can avoid past mistakes and capitalize on past successes. Did you learn anything useful that you (and others) should remember to do again? Learning from how the work was planned, managed, and performed forms the accumulated wisdom of organizational culture. If it’s not written down somewhere, the wisdom becomes folklore, subject to misinterpretation and embellishment. Unless you plan to build campfires and share your wisdom stories in nightly rituals, you better write down enough stuff so that you, and your organization are learning.
Honesty: In business organizations, people usually want to share their perspectives honestly. Deliberate lies are actually quite rare. But we do fall into bad habits and “myths.” A classic estimation myth is when engineers say, “We always have to double our estimates because management always cuts them in half!” Then the managers tell me, “We always cut the engineering estimates in half because we know that they’re doubling them!” Organizations get locked into this “estimation dance” and no one is documenting what it really takes to get a job of a particular magnitude done. “You know, the last time we tried something like this, we said we could do it in six months and it was a two year death march. Let’s not do that again!” Whenever opinions disagree, chances are there is some data missing. You need to be recording enough data so that informed choices can be made rather than letting the strongest opinion survive.
Whine #2: “I’m an ARTIST! Planning and documenting will destroy my creativity!”
Have you ever spent time with a genuine artist? Not just painters but musicians, and yes, even athletes — anyone who can create a product or performance that is enjoyed and/or respected by others. With few exceptions (there are always singular geniuses in any field, if you are truly one of them, then bless you!), artists rely on training and practice, practice, practice to develop a foundation of demonstrable discipline on which they build their creative results. Having spent years as a musician myself, I am always reminded that the performance (finished product) I am experiencing is the result of untold hours of the disciplined application of technique.
Think of architecture. There are volumes of requirements, constraints, restrictions, and rules that are imposed on architecture in order for buildings to be safe, habitable, and comfortable. Does this mean that all buildings look alike? Of course not! Architects exercise remarkable creativity on a foundation of disciplined wisdom.
Â Whine #3: “We can’t say ‘no’ to our customers!”
When I hear this, my immediate reaction is “Wow! So you give your customers everything they want, when they want it, and with a quality that keeps them satisfied?” When I ask this question, I typically find some folks staring at their shoes and rather sheepishly saying, “Well, not exactly.”
“Ohhh, so you’re DOING ‘no’, you’re just not saying ‘no’!” This gets back to the software myths that I discussed earlier. This is really an honesty problem, not a discipline problem.
But this does have a discipline component. As a group with a finite population (you can count the number of people in your group), you have a finite capacity for work. Do you know what that capacity is? You should. And the easiest way to find out is to have documented requirements and a documented plan to satisfy them.
Whine #4: “Everything we get is a #1 priority!”
Actually, you should be grateful that your customers and/or managers have established this kind of an environment for you. Because, if this is indeed true, then YOU get to pick what you want to work on next! Everything being of equally high priority is the same as everything being of equally low priority. Equal is equal. If you can’t pick what you want to work on next, then there’s some secret, hidden priority out there, somewhere &endash; could be an honesty problem again.
Whine #5: “I work in ‘Research’ so disciplined behaviors don’t apply to the work I do!”
I find it interesting that in almost every field of study that I have read about, research seems to be practiced with incredible discipline. Look at research in physics, mechanical engineering, electronics, chemistry, etc. Logbooks or journals of performed steps are carefully recorded. Scientific experiments are rigorously performed. This is because research is usually performed under a relatively small, strict budget and no one wants to pay to explore the same potential solution twice, especially when it isn’t the correct solution. But in software, research is often confused with “play”.
Whine #6: “Why can’t we just buy the ‘ideal’ way to perform our work, a way that matches the unique, special needs of our environment?”
You can always buy a process. As a matter of fact, there is a cottage industry based upon selling procedures, document templates, role descriptions, etc. As to whether the purchased processes will meet the special, unique needs of your environment, only you can answer that. So they may need some adjustment. However, my experience in organizations has shown that the most difficult part of software process improvement is getting the human beings in the organization to change their behaviors in order to use the processes to achieve intended results.
I hope that you’ve enjoyed sharing some of my favorite whines. As time goes on and our whines age, new and more complex flavors will emerge!