I just read this bit of Code Complete by Steve McConnell. It's so true! I wanted to share it with you... :)
Comments on Popular Methodologies
If you look carefully at the popular methodologies -- including structured design and object-oriented design -- you'll see that each consists of two main elements:
Some methodologies contain a third element:
Restricting the meaning of the term "design" to the first two elements implies that the hard part of design is decomposing a program into smaller subprograms and further implies that the implementation of the subprograms isn't challenging enough to be worthy of discussion.
It's true that a good system decomposition is valuable. It's not true that the need for good design stops as soon as a sound structure has been identified. A great deal of work still needs to be done within individual modules and routines after they've been identified.
The third element that accompanies some design methodologies, the idea that any design methodology should be used exclusively, is particularly harmful. No methodology can account for all the creativity and insight required to design a system. Imposing an exclusive design methodology on the design activity stiffles important thought processes.
All too often, choice of a design methodology is a religious issue -- you go to a revival meeting and hear sermons from some of the prophets of structured objectness and then return to your shrine to write a few holy programs on clay tablets. After such conversion, you aren't allowed to stray into the pagan territory of other methodologies. This fanaticism violates the constitutional separation of church and software engineering.
:lol:
Comments on Popular Methodologies
If you look carefully at the popular methodologies -- including structured design and object-oriented design -- you'll see that each consists of two main elements:
- Criteria for decomposing a system into subprograms
- Verbal or graphical notation for expressing the decomposition
Some methodologies contain a third element:
- Arm-twisting to prevent your using other methods
Restricting the meaning of the term "design" to the first two elements implies that the hard part of design is decomposing a program into smaller subprograms and further implies that the implementation of the subprograms isn't challenging enough to be worthy of discussion.
It's true that a good system decomposition is valuable. It's not true that the need for good design stops as soon as a sound structure has been identified. A great deal of work still needs to be done within individual modules and routines after they've been identified.
The third element that accompanies some design methodologies, the idea that any design methodology should be used exclusively, is particularly harmful. No methodology can account for all the creativity and insight required to design a system. Imposing an exclusive design methodology on the design activity stiffles important thought processes.
All too often, choice of a design methodology is a religious issue -- you go to a revival meeting and hear sermons from some of the prophets of structured objectness and then return to your shrine to write a few holy programs on clay tablets. After such conversion, you aren't allowed to stray into the pagan territory of other methodologies. This fanaticism violates the constitutional separation of church and software engineering.
:lol: