I recently came across a much earlier HN submission[0] to this paper. While the points the commenters made (with excellent citations) are correct, I feel that a charitable reading of the paper finds that it is not in opposition.
In the paper, Parnas and Clements do reject an "ideal, rational, top-down" design process as being a goal for software development. However, their subsequent claim that project documentation should "fake" this process is more controversial. I interpret the paper's claims as such: when the authors say to "fake" the process, they are not saying to pretend to the world that the top-down design process occurred all along. In fact, they prescribe a document to describe alternative design decisions that were rejected, just so that the ideal view is contrasted with the reality of the design process. They note that, in mathematics education, proofs are "cleaned up" so as to focus on the specific strengths or qualities of the proof. Textbooks are perhaps the ultimate example of this. I have heard mention of this practice elsewhere, before encountering this paper, and I don't find an issue with that. To me, this comes down to being in alternative modes: as an author or as a learner. Designers can and should be both, each at their own times. The point of having polished requirements documents, architecture documents, and so on, is so that other designers can efficiently learn from the documented design. Otherwise, the learners would need to collect information from a myriad of sources, trying to piece together the knowledge, skill, and experience that went into the design.
In concurrence with the citations in [0], I agree that requirements/specifications change, and that a seemingly haphazard design process that isn't top-down still has its own sense. I think of peoples' actions as obeying numerous different systems of logic. Values (taken as axioms) and inference/derivation rules don't have to strictly be "formally logical". If an action seems nonsensical from an economic standpoint, it may not be from an emotional standpoint, and so on. There is no inherent reason to prefer some set of axioms, and agents may hold many different sets (and therefore different logics) for different times. What is important is consistency within a logical system. In fact, during design, people surely have partially-formed requirements documents, and whatnot, in mind. So I say that top-down design is not suitable for someone in the process of designing, but lends itself to someone learning about a design (with the caveat that the roads not taken are also documented). The two approaches are two sides of the same coin. Or: don't require someone to create the universe to create an apple pie, but let the physicists have a slice as they figure it out.
I recently came across a much earlier HN submission[0] to this paper. While the points the commenters made (with excellent citations) are correct, I feel that a charitable reading of the paper finds that it is not in opposition.
[0] https://news.ycombinator.com/item?id=11101358
In the paper, Parnas and Clements do reject an "ideal, rational, top-down" design process as being a goal for software development. However, their subsequent claim that project documentation should "fake" this process is more controversial. I interpret the paper's claims as such: when the authors say to "fake" the process, they are not saying to pretend to the world that the top-down design process occurred all along. In fact, they prescribe a document to describe alternative design decisions that were rejected, just so that the ideal view is contrasted with the reality of the design process. They note that, in mathematics education, proofs are "cleaned up" so as to focus on the specific strengths or qualities of the proof. Textbooks are perhaps the ultimate example of this. I have heard mention of this practice elsewhere, before encountering this paper, and I don't find an issue with that. To me, this comes down to being in alternative modes: as an author or as a learner. Designers can and should be both, each at their own times. The point of having polished requirements documents, architecture documents, and so on, is so that other designers can efficiently learn from the documented design. Otherwise, the learners would need to collect information from a myriad of sources, trying to piece together the knowledge, skill, and experience that went into the design.
In concurrence with the citations in [0], I agree that requirements/specifications change, and that a seemingly haphazard design process that isn't top-down still has its own sense. I think of peoples' actions as obeying numerous different systems of logic. Values (taken as axioms) and inference/derivation rules don't have to strictly be "formally logical". If an action seems nonsensical from an economic standpoint, it may not be from an emotional standpoint, and so on. There is no inherent reason to prefer some set of axioms, and agents may hold many different sets (and therefore different logics) for different times. What is important is consistency within a logical system. In fact, during design, people surely have partially-formed requirements documents, and whatnot, in mind. So I say that top-down design is not suitable for someone in the process of designing, but lends itself to someone learning about a design (with the caveat that the roads not taken are also documented). The two approaches are two sides of the same coin. Or: don't require someone to create the universe to create an apple pie, but let the physicists have a slice as they figure it out.