3 ms·

Hah, I might have agreed before I worked on a credit card processing system. There were plenty of rules alright, but it's possible to abide by all the rules wit

Hah, I might have agreed before I worked on a credit card processing system. There were plenty of rules alright, but it's possible to abide by all the rules without actually making a secure system. Some of the rules made it harder to create a secure system because they did not reflect the state of the art, or they made adding additional security too burdensome to implement. In the end, you can't force competence through rules.

closewith 4y ago
> In the end, you can't force competence through rules. I mean, we have in all other forms of engineering. Why is software different?
- bigbillheck 4y ago
  Sounds like a pretty good argument for 'software engineering is not engineering'.
  - closewith 4y ago
    I think we can all (mostly?) agree that most of what's called software engineering doesn't live up to the standards (including responsibilities of the developers/engineers) of the other formalised engineering disciplines.
- seti0Cha 4y ago
  The software world evolves much faster than any of the engineering disciplines and has fewer physical constraints. The requirements for software are rarely fully specified when construction starts. Software is faster to build, deploy and fix so getting it right the first time is not as important. The environment in which it is deployed changes rapidly and in entirely unexpected ways, which is not the case for things built by engineers. There are plenty of differences. In practice, software is more like a craft than an engineering discipline.
  - closewith 4y ago
    > The software world evolves much faster than any of the engineering disciplines and has fewer physical constraints. The requirements for software are rarely fully specified when construction starts. Software is faster to build, deploy and fix so getting it right the first time is not as important. The environment in which it is deployed changes rapidly and in entirely unexpected ways, which is not the case for things built by engineers. These are all artefacts of software development as we practice it, rather than truisms. > In practice, software is more like a craft than an engineering discipline. Maybe we should reserve the term software engineering for the applications of software development where rigour is involved?
    - seti0Cha 4y ago
      > These are all artefacts of software development as we practice it, rather than truisms. Well, they're not laws of nature or anything. But pragmatically, how could it be otherwise? When it comes to bridges and buildings, correctness beats timeliness, but when it comes to software the opposite is usually true. There are exceptions of course (e.g. medical software) > Maybe we should reserve the term software engineering for the applications of software development where rigour is involved? Agree.

closewith 4y ago

> In the end, you can't force competence through rules. I mean, we have in all other forms of engineering. Why is software different?

bigbillheck 4y ago
Sounds like a pretty good argument for 'software engineering is not engineering'.
- closewith 4y ago
  I think we can all (mostly?) agree that most of what's called software engineering doesn't live up to the standards (including responsibilities of the developers/engineers) of the other formalised engineering disciplines.
seti0Cha 4y ago
The software world evolves much faster than any of the engineering disciplines and has fewer physical constraints. The requirements for software are rarely fully specified when construction starts. Software is faster to build, deploy and fix so getting it right the first time is not as important. The environment in which it is deployed changes rapidly and in entirely unexpected ways, which is not the case for things built by engineers. There are plenty of differences. In practice, software is more like a craft than an engineering discipline.
- closewith 4y ago
  > The software world evolves much faster than any of the engineering disciplines and has fewer physical constraints. The requirements for software are rarely fully specified when construction starts. Software is faster to build, deploy and fix so getting it right the first time is not as important. The environment in which it is deployed changes rapidly and in entirely unexpected ways, which is not the case for things built by engineers. These are all artefacts of software development as we practice it, rather than truisms. > In practice, software is more like a craft than an engineering discipline. Maybe we should reserve the term software engineering for the applications of software development where rigour is involved?
  - seti0Cha 4y ago
    > These are all artefacts of software development as we practice it, rather than truisms. Well, they're not laws of nature or anything. But pragmatically, how could it be otherwise? When it comes to bridges and buildings, correctness beats timeliness, but when it comes to software the opposite is usually true. There are exceptions of course (e.g. medical software) > Maybe we should reserve the term software engineering for the applications of software development where rigour is involved? Agree.