Ask Slashdot: On Good Software Design Processes

Marko Rauhamaa asks: "I'm a software manager in a medium-size technology company. Today I ran into a professional argument with my superiors about our company's software design process, which, I suppose, is fairly standard: The software team is to write one or more MS Word documents that have predefined section headings. The documents should describe all aspects of the coding phase that is about to begin. Then the documents are peer-reviewed, polished and submitted under document control. Questions: What kind of design process do the successful free-software projects have (Linux, gcc, Apache, XFree86, etc)? In your experience, how often are design documents revisited after the project? Have design documents helped in technology transfers (that is, have they been more helpful than the source code alone)? Are engineers good at writing design documents? Have you been able to read design documents written by other engineers? Have old design documents been kept up to date with the changes in the implementation? Has the quality of your products been better because of design documentation?"

Hmmm

What you describe doesn't sound like a development process at all. It sounds like a documentation burr... A development process is a pretty ethereal animal (those that may or may not exist, depending on whom you ask).

I've personally not worked on open source projects (yet) but I imagine that they are vastly different than any commercial effort. Seems to me that managing gratis developers is like herding cats - if you try to control them, they'll simply leave.

But, I would strongly recommend Steve McConnell's book on Rapid Development, and Code Complete while you're at it.

The RD book - well, eat it. Read it cover to cover twice, and with that knowledge in your head, use what fits your project and developers.

Your people may like to do thorough design up front, and follow the traditional 'waterfall' process, but that doesn't stand up well to changing specs.

Incremental development seems to work well where I work. We have a small team, and in-house users, so feedback and even design changes can happen pretty quickly..

You'll need to look at the risks your project is facing as well as a number of other factors - i.e. do you subcontract, buy COTS stuff, use strict CM and are you subject to stringent V&V?? Who are your users, how skilled are your people? Look where you fall on the Capability Maturity Model (1.1 release) hierarchy and how you rank per ISO 9000-3. If nothing else, you'll get some ideas.

As you can guess, there's a huge number of variables that go into defining a successful process. The Software Engineering Institute at Carnegie-Mellon University [cmu.edu] may prove helpful, but I would recommend the aforementioned book (RD) first.

My software design process

This is how the shoeboy does things:

1. All the probable users are asked to contribute their thoughts on what the project was supposed to do. Most of them suggest things entirely unrelated to the description of the project.
2. All reasonable suggestions are torn up and fed to a goat.
3. The goat is sacrificed in the middle of an inverted pentagram while the PM chants "CTHULHU FNAGN" (this step is optional)
4. The development group works out a good application framework on a whiteboard. The least popular member of the group is then assigned to create a powerpoint detailing the proposed framework.
5. Out of bitterness, the guy writing the powerpoint discards the teams ideas and writes his own. The powerpoint is then sent to management.
6. Management approves or vetoes the project based on the color scheme used.
7. The team suddenly finds themselves commited to a shitty framework. The alpha geek on the team blames the PM and begins playing political games to get him/her replaced.
8. Deciding that misery loves company, the team asks the Unix and NT admins what platform the app should run on.
9. The Unix wookies and the NT trolls declare total war on each other and the PM gets cc'd on every message in the resulting flame war.
10. The team hires a bunch of contractors to help develop the project.
11. Performance review time. Everyone tries to look good at the expense of others. Massive flame wars erupt.
12. Team begins to develop application while attempting to keep PM in the dark.
13. PM gets revenge by requesting customer feedback on the proposed feature set.
14. Team vetoes all customer requests, promises to include them in the next version.
15. Management hears the customer complaints. Demands more powerpoints.
16. Reorg time. PM now reports to a new manager.
17. Team missed deadline for first beta as they are working on powerpoint slides.
18. Cubicle move. Work interrupted as everyone in the building starts moving cubes to the tune of 'pop goes the weasel'. When the music stops, they all rush to a new cube except for one sluggish contractor who is promptly fired.
19. Team missed second beta deadline due to the loss of the contractor fired in step 18.
20. Management decides that the project will never get finished, cancels it.

This isn't the best way to design software, but it seems to be a common method.
--Shoeboy