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?"

Comments

My software design process

[Shoeboy]

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