What is the equivalent in other fields that build things? I mean, project management must be studied in other disciplines, and what have they come up with?
Thank you! I wish more people would go and learn what engineering is in other fields before trying to discuss software engineering. I recently had an argument on HN about the particulars of this topic: https://news.ycombinator.com/item?id=8633616
Another book I can recommend on the subject is Petroski's To Engineer is Human.
The article points out in the beginning that borrowing project management practices from other disciplines is what we tried to do (which gave us The Waterfall method) and it doesn't work.
That said, I agree with the GP in that I was expecting more focus on actual software matters, like how to test the reliability of a system before it's built etc.
I don't think waterfall is actually used in other disciplines, perhaps we were just cargo culting back then?
But my question is: if SE is supposed to be based on a theory of project management, then what is the theory used in other disciplines? Or do project management not see that as their underlying theory, but rather something more hard like physics or chemistry?
It sounds like there must be a general field of project management out there...getting people to apply technical skills to get things done. It is probably a soft science, but definitely necessary. So why not talk about this aspect SE as a sub-field at that field rather than as an aspect of a more hard science (computer science)?
> I don't think waterfall is actually used in other disciplines, perhaps we were just cargo culting back then?
I think this is half right. There was quite a bit of cargo-culting going on. But the fundamental error was to try to apply the project-management process for the construction of other kinds of artefacts to the design of software. I wrote about this very topic here:
You're correct that no other engineering discipline attempts to use waterfall-style project management of its design process. They don't really use it in the construction process either (in practice, design tends to continue alongside construction), though it probably has at least been attempted.
It was no surprise to see that the authors of this piece are in fact among the originators of the Rational Unified Process. They claim to have corrected their mistake; in fact they are still pushing the same wrongheaded ideas as they were in the 1980s.
"They don't really use it in the construction process either (in practice, design tends to continue alongside construction)..."
For something like a high-rise office tower, the design decisions you can change after construction is in progress are quite limited. For example, you can't add ten more floors to the building as an afterthought, since that would involve adding extra elevator shafts, emergency stairways, water and sewage lines, etc. that would cause significant disruption to the floors of the building that have already been built. Similarly, redesigning the layout of a floor to accommodate twice as many people would require similar changes to stay compliant with building and safety codes.
I suppose if you're constructing a single-family house, there's much more leeway to change the design during construction - but it would still be costly.
"The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development."
> It sounds like there must be a general field of project management out there
Yes, project management is a discipline in itself. Why the article is calling its project management framework for software development "software engineering" is not clear. Probably because it sounds more promising; it promises to be the silver bullet:
