This was a major message of the Agile movement, which opened its Manifesto with the words: “We are uncovering better ways of developing software by doing it and helping others do it.”
To a great extent, this was a reaction to the Capability Maturity Model era, in which the actual act of software coding was often overshadowed by achievement of maturity levels, implementation of key process areas, documentation of processes, generation of artifacts and tallying of metrics.
As noted in the SEI paper, “CMMI® or Agile: Why Not Embrace Both?”:
… if CMMI is used in the pursuit of maturity level numbers, the resulting process improvement efforts can sometimes lose sight of customer value, product, project value, and practical business goals.
The point here is that well-intentioned improvement efforts, whether initiated by management or by consultants, can all too easily prove a distraction to the actual production of working software to be used by real people, often to the detriment of everyone involved.
In particular, you would do well to avoid any sort of zealotry concerning any particular model being peddled by management consultants: while most such models can be useful, all are imperfect representations of reality, and most tend to take on a life of their own after a certain period of time. For more on this topic, see the Pagan Tuna post, “Model Mania.”
It would be wise to pay heed to the advice on this subject from Steve Jobs: The Lost Interview:
People get confused… companies get confused. When they start getting bigger they want to replicate their initial success. And a lot of them think, well somehow there’s some magic in the process of how that success was created. So they start to try to institutionalize process across the company. And before very long, people get very confused that the process is the content. That’s ultimately the downfall of IBM. IBM has the best process people in the world. They just forgot about the content. And that’s a little what happened at Apple too [which led to the Apple Lisa, a market failure in the 1980s]. We had a lot of people who were great at management process, they just didn’t have a clue as to the content. In my career, I’ve found that the best people are the ones that really understand the content – and they are a pain in the butt to manage, but you put up with it because they are so great at the content. That’s what makes good products: it’s not process, it’s content.
It’s ok to learn from the various software development gurus and movements you will find around you, but it’s best not to declare absolute allegiance to any of them. Remember that many consultants, speakers and authors are primarily interested in creating reliable revenue streams, and that their interests will not always coincide with yours. Also, I’ve worked with teams devoted to the CMMI as well as teams devoted to Agile and, in both cases, I’ve found mindless conformance to a set of precepts to be more harmful than any of the practices either of these movements was intended to correct.
Wired: In your experience, what’s the best process for design?
Brooks: Great design does not come from great processes; it comes from great designers.
He continues, “Remember, outcomes are what matter—not the process, not controls, or, for that matter, what work you complete.”