Problems with Process

Douglas C. Schmidt
C++ Report
May 1996

My previous Editor's Corner focused on dysfunctional traits I've observed while working on software projects during the past decade. Many traits (such as "Death by Quality") originate from outdated or ineffective development processes. A development process consists of the tasks performed and the artifacts produced when building software.

Effective development processes are essential for producing high quality software, particularly for large-scale systems. However, identifying and instituting good software processes is remarkably elusive. In this Editor's Corner I describe some common problems I've encountered with existing development processes and outline some concrete steps that can help produce better software.

Common Problems with Software Development Processes

The following are some common process-related problems I've observed over the years:

A Case Study in Frustration

I've worked on several projects over the years that exhibited all the process-related problems described above. One distributed systems project was particularly notable. On this project, programmers weren't allowed to write any code until they'd fully documented all the interfaces in a CASE tool. There were two motivations for this approach:

Although these motivations are reasonable in theory, in practice there were several problems:

This project was a poster child for the problems that arise when a development process runs amok. Not only did they choose the wrong process and tools, but they had an entrenched process bureaucracy that ignored developer feedback until the project derailed completely. By that point, the original top-down designs and implementations were essentially useless and had to be completely reworked. Because the development process didn't allow rapid prototyping, the development team wasted person-years of effort that could have been spent building prototypes to reduce risk. These problems weren't recognized until well into the project, however, when they were quite expensive to fix.

Towards a Product-Oriented Process

So what can we do to alleviate the problems with existing processes? In my experience, successful organizations employ product-oriented processes that help, rather than hinder, software productivity. Some specific techniques I can suggest for instituting product-oriented processes include the following:

Wrapping Up

My goal in discussing topics like process and organization structure in the C++ Report is to raise awareness of the need for better software development practices. The longer I work with software, the more I realize that many of our toughest challenges are rooted in process rather than technology. To be effective, however, solutions to these challenges must harmonize with contemporary technology practice and respect the contribution of technologists.

I'm concerned that our industry is increasingly being driven by the false prophets of Process and Methodology. This leads to simple-minded solutions to complex software development processes, which can cause far more problems than they solve. To counteract this trend, developers must become more proactive in shaping and improving the software processes they perform. However, this topic is becoming too far removed from C++. Therefore, next month's Editor's Corner will focus on tips for building C++ frameworks that are portable across different OS platforms and compilers.

I'd like to thank Jack Reeves, Tim Harrison, Prashant Jain, and Irfan Pyarali for their comments on this editorial.


[1] F. P. Brooks, The Mythical Man-Month, Addison-Wesley, Reading, MA, 1975.

Back to C++ Report Editorials home page.