"We, the purveyors of the most momentous technological change period in the history of business, still don’t “get it.” Every publication—from ComputerWorld to Business Week—trumpets to business leaders that “business will never be the same.” Why then, do we insist that software development and management practices won’t undergo dramatic changes also? We seem to accept the idea that everything is changing to fit this 21st Century Internet world; everything is changing, that is, except for you and me, and the ways we’re comfortable doing what we do. Does that make sense?"
"In a Dilbert cartoon, Wally the co-worker bemoans the fact he has no impact on results, but he can take solace in having “process pride.” As Wally says, “Everything I do is still pointless, but I’m very proud of the way I do it.” Maybe it’s time for a new outlook. It’s time for an era of results over process, understanding over documents, collaboration over control, adaptation over optimization."
Some people think of software development as an engineering activity. That comparison is actually more dangerous than useful, as leads us in the wrong direction. Comparing software development with engineering leads us to ask about "specifications" and "models" of the software, of their completeness, correctness, and currency. These questions lead in the wrong direction because we actually don't care, past a certain point, whether the models are complete, whether they correctly match the "real" world (whatever that is), and whether they are up-to-date with the current version of the code. Attempting to make them complete, correct and current past a certain point is a waste of money. As one experienced programmer told me, "I often feel I am doing something good when I start drawing these models, but after a while I feel I have somehow passed the point of diminishing returns and my work becomes wasteful. I just don't know when I have passed that point of diminishing returns, and I haven't heard anyone talk about it." To understand and locate this point of diminishing return, we need to shift away from thinking of software development as an engineering activity, and think of it as a resource-limited, cooperative game of invention and communication. If you have trouble imagining such a thing, think of rock-climbing teams. The team members must help each other reach the top, and are resource-limited, either by daylight, food or energy. Team rock-climbing is my favorite comparison partner for software development, because so many key issues are shared between them. I should be quite clear that rock-climbing is not a metaphor or analog for software development, but rather, they are both members of the same class of games: goal-oriented, cooperative, finite. In the case of software development, there is a primary and a secondary goal. The primary goal is to deliver the system. The secondary goal is to set up for the next game, which is to extend or maintain the system, or to building a neighboring system. Failing at the primary goal makes the secondary goal irrelevant. However, succeeding at the first and failing at the second is also sad, since failing at the secondary goal interferes with success of the next game. Thinking of software development as a cooperative game directs us to more fruitful questions, particularly, the deployment of our scant people, time and money. We are led to investigate better techniques for inventing and communicating, ways to get the same net effect consuming less resources. We are led to ask about whether any particular piece of work is sufficient to its task of invention or communication. We are led to the idea that a model need not be complete, correct or current to be sufficiently useful. This notion allows us to explain the success of many projects that succeeded despite their "obviously" incomplete documents and sloppy processes. They succeeded exactly because the people made good choices in stopping work on certain communications as soon as they reached sufficiency and before diminishing returns set in. They made the paperwork adequate, they didn't polish it. "Adequate" is a great condition for a communication device to be in if the team is in a race for an end goal and short on resources.
The eXtreme Programming [3] methodology (XP) is a highly efficient and rigorous, very lightweight methodology for small teams. It calls for all the developers to sit in one large room, for there to be a usage expert or "customer" on the development staff full time, for the programmers to work in pairs, to develop extensive unit tests for their code which can be run automatically at any time, for those tests always to run at 100% for all code that is checked in, and for code to be developed in nano-increments, checked in and integrated several times a day. The result is delivered to real users every two-to-four weeks. In exchange for all this rigor in the development process, the team is excused from producing any extraneous documentation. The requirements lives as an outline on collections of index cards, the running project plan is on the whiteboard. The design lives in the oral tradition among the programmers, in the unit tests and in the oft-tidied-up code itself.