4 ms·

> It's very difficult to define a specification that works as intended, even with tools. Agree, we are in the stone age in software design and dev. We have not

> It's very difficult to define a specification that works as intended, even with tools. Agree, we are in the stone age in software design and dev. We have not figured out a good way to communicate the design of complex systems in a way the business can understand.

rramadass 5mo ago
Nope; this is just a silly trope which gets repeated without thought. The fact that it is hard to do does not mean we don't know how to do it. Everything exists and was known from 1960s/1970s. People are just not studying, adapting and using the well-known standards/techniques. Standard Engineering is built on them and Software Engineering adapts/extends those for its own needs. Specification (technical standard) (general)- https://en.wikipedia.org/wiki/Specification_(technical_standard) https://en.wikipedia.org/wiki/Specification_(technical_stand... Software Requirements Specification - https://en.wikipedia.org/wiki/Software_requirements_specification https://en.wikipedia.org/wiki/Software_requirements_specific... Software Design Specification - https://en.wikipedia.org/wiki/Software_design_description https://en.wikipedia.org/wiki/Software_design_description Formal Specification - https://en.wikipedia.org/wiki/Formal_specification https://en.wikipedia.org/wiki/Formal_specification System Requirements Specification - https://en.wikipedia.org/wiki/System_requirements_specification https://en.wikipedia.org/wiki/System_requirements_specificat... All have been collected in a Software Engineering Body of Knowledge book - https://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K...
- RaftPeople 5mo ago
  Those example are exactly the problem that has not been solved yet. They are the best we can do so far but are pretty inadequate to communicate complex designs in a way that a person can easily absorb all of that info and then reason about whether the resulting system is adequate. As complexity grows, the value of those artifacts reaches significant limits that are typically dealt with through brute-force mental effort of the people involved.
  - rramadass 4mo ago
    The above resources are not examples but methodology/process using various techniques to produce various artifacts which specify the requirements unambiguously. It is up to the practitioner to choose his techniques and use the methodologies (tweaking as needed) in a systematic manner to convey the requirements to stakeholders for approval. Lots of complex systems have been built and understood using the above. As system complexity grows, doing the above is even more important even though it be hard. Some references; 1) A Rational Design Process: How and Why to Fake It by David Parnas and Paul Clements (pdf) - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei... 2) How Designers Work by Henrik Gedenryd - https://news.ycombinator.com/item?id=48352065 https://news.ycombinator.com/item?id=48352065

rramadass 5mo ago

Nope; this is just a silly trope which gets repeated without thought. The fact that it is hard to do does not mean we don't know how to do it. Everything exists and was known from 1960s/1970s. People are just not studying, adapting and using the well-known standards/techniques. Standard Engineering is built on them and Software Engineering adapts/extends those for its own needs. Specification (technical standard) (general)- https://en.wikipedia.org/wiki/Specification_(technical_standard) https://en.wikipedia.org/wiki/Specification_(technical_stand... Software Requirements Specification - https://en.wikipedia.org/wiki/Software_requirements_specification https://en.wikipedia.org/wiki/Software_requirements_specific... Software Design Specification - https://en.wikipedia.org/wiki/Software_design_description https://en.wikipedia.org/wiki/Software_design_description Formal Specification - https://en.wikipedia.org/wiki/Formal_specification https://en.wikipedia.org/wiki/Formal_specification System Requirements Specification - https://en.wikipedia.org/wiki/System_requirements_specification https://en.wikipedia.org/wiki/System_requirements_specificat... All have been collected in a Software Engineering Body of Knowledge book - https://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K...

RaftPeople 5mo ago
Those example are exactly the problem that has not been solved yet. They are the best we can do so far but are pretty inadequate to communicate complex designs in a way that a person can easily absorb all of that info and then reason about whether the resulting system is adequate. As complexity grows, the value of those artifacts reaches significant limits that are typically dealt with through brute-force mental effort of the people involved.
- rramadass 4mo ago
  The above resources are not examples but methodology/process using various techniques to produce various artifacts which specify the requirements unambiguously. It is up to the practitioner to choose his techniques and use the methodologies (tweaking as needed) in a systematic manner to convey the requirements to stakeholders for approval. Lots of complex systems have been built and understood using the above. As system complexity grows, doing the above is even more important even though it be hard. Some references; 1) A Rational Design Process: How and Why to Fake It by David Parnas and Paul Clements (pdf) - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei... 2) How Designers Work by Henrik Gedenryd - https://news.ycombinator.com/item?id=48352065 https://news.ycombinator.com/item?id=48352065