Re:Computer science is not software engineering
by PaulDavisThe1st on Saturday December 26, 2020 @10:57AM
(#25544157)
That's mostly because the performance requirements don't exist, certainly not in the same sense as they do for mechanical engineering.
Imagine someone designing and constructing a bridge, and right after it was possible to walk gingerly across one part of it, the people in charge of the project said "hmm, could you put a parking area in the middle?". And then, right after you had done that, came back and said "great, but we'd like to make the whole thing a double decker so we can run a train line across the lower level?". Miraculously, you pull this off, and then they announce that they've realized that the bridge needs to open in the middle to allow large boats through.
We (generally) do not allow engineering projects rooted in the physical world to have fluid specifications, because of the cost and complexity of doing so.
Although there is a real cost and huge complexity to allowing software engineering to accomodate goal flexibility as much as we do, it is vastly less than would be the case for most mechanical and chemical engineering projects.
And the reality is that human goals do change as exposure to a project takes place. There are probably many people involved in bridge specifications who wish they could have gone back and significantly altered some part of the design, based on things learned during construction and early use. But we don't allow that, and so we're left with an impression that only non-software engineers are good at handling performance specifications. It's not true.
Imagine someone designing and constructing a bridge, and right after it was possible to walk gingerly across one part of it, the people in charge of the project said "hmm, could you put a parking area in the middle?". And then, right after you had done that, came back and said "great, but we'd like to make the whole thing a double decker so we can run a train line across the lower level?". Miraculously, you pull this off, and then they announce that they've realized that the bridge needs to open in the middle to allow large boats through.
We (generally) do not allow engineering projects rooted in the physical world to have fluid specifications, because of the cost and complexity of doing so.
Although there is a real cost and huge complexity to allowing software engineering to accomodate goal flexibility as much as we do, it is vastly less than would be the case for most mechanical and chemical engineering projects.
And the reality is that human goals do change as exposure to a project takes place. There are probably many people involved in bridge specifications who wish they could have gone back and significantly altered some part of the design, based on things learned during construction and early use. But we don't allow that, and so we're left with an impression that only non-software engineers are good at handling performance specifications. It's not true.