9 ms·

Six types of bridges... Were you serious? There are definitely ways to apply formal engineering methods to software that greatly help its development. Computer

Six types of bridges... Were you serious? There are definitely ways to apply formal engineering methods to software that greatly help its development. Computer programming is not a special snowflake. It's a field that (in many areas) refuses to grow up.

sillysaurus3 9y ago
Forcing it to grow up would harm it, though. The engineers would move to companies that don't force those kinds of constraints. It's important to keep in mind what "growing up" translates to: slowing down. This has both economic and competitive implications. Sometimes it might be a win, but the vast majority of the time your ability to move quickly (and yes, occasionally break things) is an advantage.
- lilott8 9y ago
  Yes and no. It is a natural progression of the industry. Those who cannot do "formal engineering" probably don't belong in engineering roles. Engineering, in general, imho, can be distilled down to this: Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints. If someone as an SE cannot do that, they really have no business being anywhere near any field of engineering.
  - pitay 9y ago
    Depends on the constraints you want to prove that the program will uphold. Some constraints may be impossible to prove, especially in non-real time contexts. For example, a program must run on a platform that doesn't have everything formally defined or have guarantees. If a program relies on that platform and that influences the program in a way that makes the constraint reliant on the platform, then you are out of luck. Another issue is choosing the constraints that the program will operate under. You would hope that the clients would give you the requirements including the constraints the software must operate under. But this isn't often the case. Having an incremental approach which includes clarifying requirements by mapping what the clients need to do to get their work done, which includes recording the specific steps that they perform or need to perform works pretty well when clients don't provide the requirements or constraints upfront. I am relatively ignorant on formal engineering, but I do like that you have provided a fairly clear definition, which was "Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints". It is better than the people saying know more math, without saying how, or what, or why it is useful in any clear way, and saying software is math just doesn't cut it.
    - lilott8 9y ago
      That is a great counter example. I expect there to be a slow migration to platforms like [this formally verified microkernel](https://sel4.systems/ https://sel4.systems/). This will take time and a tremendous amount of effort. But will ultimately address the counter example. In the conclusion of this migration, this puts the SE field into line with the rest of engineering. Choosing the constraints for a project is no different in the context of CS than the context of any other fields -- electrical, mechanical, etc. It is a conversation, as you stated. This helps in many ways: it helps the developer understand exactly what the client wants, helps the client understand exactly what they are going to get, and helps build an implicit timeline replete with discrete and obvious deliverables and (if done correctly) those deliverables are fairly modular. Thanks! I, too, get frustrated that people just say 'math! math! math!' That isn't helpful or meaningful. This is a conclusion I came to after talking to quite a few of my friends and colleagues in different engineering disciplines.
      - pitay 9y ago
        Thanks for the information, it is very much appreciated. I was a little frustrated that comments on this thread had people saying you should learn the math and prove your programs but providing no information on how to do so. It would be great if provided resources to show people how to do it. Or even better, provide a project that they worked on and show how they used formal methods to move through the project in detail, which would be wonderful. If someone wants to promote formal methods, then should not just argue for it, but teach it, even a tiny bit. That would get a way better reception. A little off topic, but it would be great if there was a method/system which could provide requirements tracking down the set of artifacts to where you could point to a bit of source code and say it implements that certain requirement. Sort of like a chain of responsibility for code and associated documents. That might be a pipe dream, I don't know. Anyway, thanks for the information, I remember seL4 being mentioned in discussion of the sorry state of software on medical devices, but had forgotten it until you mentioned it. Thanks.
        lilott8 9y ago
- Retric 9y ago
  The current default is for people to work extremely hard and make minimal progress in software. Startups or giants most development is horribly inefficient. So, I don't think there is much to defend about how things actually work in practice.
  - nautilus12 9y ago
    I agree with this. Anything is better than how its currently done
- pharrington 9y ago
  As far as I've seen, there are generally more inefficient and unsustainable ways of doing anything than efficient and sustainable ways. If this is true, the most likely to occur software implementations are most likely wrong, and making money from these wrong implementations by exploiting their low burden of knowledge and low initial cost serves mostly to create a positive feedback loop of less and less efficient and sustainable software systems. Assuming civilization is going to last and keep using software longer than your own lifespan, this positive feedback loop is a bad thing.
pvg 9y ago
It is a special snowflake because the semantics and correctness of nontrivial programs are often in the eye of the beholder (is Microsoft Word or Google Search 'correct'?). This isn't the case for bridges, cars or toasters. It's not just a matter of adding magic engineering dust until programming is engineering.
- Denzel 9y ago
  No, the correctness is in the eye of a spec. Now, whether companies formally define their specs is a different story. Many startups don't. With that said, if Microsoft Word meets the given spec, then it's correct. One way to prove this correctness is with testing. This is the case for bridges as well. If I hand a spec to an engineering firm requesting a bridge from A to B at any given price. Well then, there's a lot of bridges that satisfy those constraints. Just because many software companies today don't choose to formally specify a spec and prove a programs correctness upon delivery doesn't mean it's a special snowflake. It just means those teams are immature. Sometimes software development doesn't require a mature team. Like most decisions, there's a cost and timing tradeoff.
  - stale2002 9y ago
    The problem with this line of thinking is that the problems that matter are not related to 100% implementing the spec correctly. The problems that matter are in the design of the spec to begin with. The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. And do you know what the best way is to test whether you got the spec right? You deploy and see if the feature gets traction. The "spec" that matters is the success of the business. And building a product, and releasing it, is the way to formally test if your feature is "correct" according to the spec that is The Market.
    - jolux 9y ago
      >The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. It's both, though. You also can't tell if you've implemented them correctly if you don't have a formal spec.
deleted 9y ago
[deleted]
mpweiher 9y ago
Actually, it is fundamentally different in that just building the thing / just running the experiment is cheaper than doing the simulations or proofs. Every other discipline does simulations because actually running the experiment is magnitudes more expensive and time consuming. See "Why software development is an engineering discipline" https://www.youtube.com/watch?v=zDEpeWQHtFU
- TeMPOraL 9y ago
  I agree. The primary thing distinguishing software development from other engineering fields is that the cost of building the product is essentially zero. Because building is what your compiler does. What a programmer does is design, and that is always influenced by the constraints of manufacturing - which, for software, are almost non-existent.

sillysaurus3 9y ago

Forcing it to grow up would harm it, though. The engineers would move to companies that don't force those kinds of constraints. It's important to keep in mind what "growing up" translates to: slowing down. This has both economic and competitive implications. Sometimes it might be a win, but the vast majority of the time your ability to move quickly (and yes, occasionally break things) is an advantage.

lilott8 9y ago
Yes and no. It is a natural progression of the industry. Those who cannot do "formal engineering" probably don't belong in engineering roles. Engineering, in general, imho, can be distilled down to this: Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints. If someone as an SE cannot do that, they really have no business being anywhere near any field of engineering.
- pitay 9y ago
  Depends on the constraints you want to prove that the program will uphold. Some constraints may be impossible to prove, especially in non-real time contexts. For example, a program must run on a platform that doesn't have everything formally defined or have guarantees. If a program relies on that platform and that influences the program in a way that makes the constraint reliant on the platform, then you are out of luck. Another issue is choosing the constraints that the program will operate under. You would hope that the clients would give you the requirements including the constraints the software must operate under. But this isn't often the case. Having an incremental approach which includes clarifying requirements by mapping what the clients need to do to get their work done, which includes recording the specific steps that they perform or need to perform works pretty well when clients don't provide the requirements or constraints upfront. I am relatively ignorant on formal engineering, but I do like that you have provided a fairly clear definition, which was "Clearly define the constraints in which your project will operate under and prove that they will hold under those constraints". It is better than the people saying know more math, without saying how, or what, or why it is useful in any clear way, and saying software is math just doesn't cut it.
  - lilott8 9y ago
    That is a great counter example. I expect there to be a slow migration to platforms like [this formally verified microkernel](https://sel4.systems/ https://sel4.systems/). This will take time and a tremendous amount of effort. But will ultimately address the counter example. In the conclusion of this migration, this puts the SE field into line with the rest of engineering. Choosing the constraints for a project is no different in the context of CS than the context of any other fields -- electrical, mechanical, etc. It is a conversation, as you stated. This helps in many ways: it helps the developer understand exactly what the client wants, helps the client understand exactly what they are going to get, and helps build an implicit timeline replete with discrete and obvious deliverables and (if done correctly) those deliverables are fairly modular. Thanks! I, too, get frustrated that people just say 'math! math! math!' That isn't helpful or meaningful. This is a conclusion I came to after talking to quite a few of my friends and colleagues in different engineering disciplines.
    - pitay 9y ago
      Thanks for the information, it is very much appreciated. I was a little frustrated that comments on this thread had people saying you should learn the math and prove your programs but providing no information on how to do so. It would be great if provided resources to show people how to do it. Or even better, provide a project that they worked on and show how they used formal methods to move through the project in detail, which would be wonderful. If someone wants to promote formal methods, then should not just argue for it, but teach it, even a tiny bit. That would get a way better reception. A little off topic, but it would be great if there was a method/system which could provide requirements tracking down the set of artifacts to where you could point to a bit of source code and say it implements that certain requirement. Sort of like a chain of responsibility for code and associated documents. That might be a pipe dream, I don't know. Anyway, thanks for the information, I remember seL4 being mentioned in discussion of the sorry state of software on medical devices, but had forgotten it until you mentioned it. Thanks.
      - lilott8 9y ago
Retric 9y ago
The current default is for people to work extremely hard and make minimal progress in software. Startups or giants most development is horribly inefficient. So, I don't think there is much to defend about how things actually work in practice.
- nautilus12 9y ago
  I agree with this. Anything is better than how its currently done
pharrington 9y ago
As far as I've seen, there are generally more inefficient and unsustainable ways of doing anything than efficient and sustainable ways. If this is true, the most likely to occur software implementations are most likely wrong, and making money from these wrong implementations by exploiting their low burden of knowledge and low initial cost serves mostly to create a positive feedback loop of less and less efficient and sustainable software systems. Assuming civilization is going to last and keep using software longer than your own lifespan, this positive feedback loop is a bad thing.

pvg 9y ago

It is a special snowflake because the semantics and correctness of nontrivial programs are often in the eye of the beholder (is Microsoft Word or Google Search 'correct'?). This isn't the case for bridges, cars or toasters. It's not just a matter of adding magic engineering dust until programming is engineering.

Denzel 9y ago
No, the correctness is in the eye of a spec. Now, whether companies formally define their specs is a different story. Many startups don't. With that said, if Microsoft Word meets the given spec, then it's correct. One way to prove this correctness is with testing. This is the case for bridges as well. If I hand a spec to an engineering firm requesting a bridge from A to B at any given price. Well then, there's a lot of bridges that satisfy those constraints. Just because many software companies today don't choose to formally specify a spec and prove a programs correctness upon delivery doesn't mean it's a special snowflake. It just means those teams are immature. Sometimes software development doesn't require a mature team. Like most decisions, there's a cost and timing tradeoff.
- stale2002 9y ago
  The problem with this line of thinking is that the problems that matter are not related to 100% implementing the spec correctly. The problems that matter are in the design of the spec to begin with. The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. And do you know what the best way is to test whether you got the spec right? You deploy and see if the feature gets traction. The "spec" that matters is the success of the business. And building a product, and releasing it, is the way to formally test if your feature is "correct" according to the spec that is The Market.
  - jolux 9y ago
    >The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. It's both, though. You also can't tell if you've implemented them correctly if you don't have a formal spec.

deleted 9y ago

[deleted]

mpweiher 9y ago

Actually, it is fundamentally different in that just building the thing / just running the experiment is cheaper than doing the simulations or proofs. Every other discipline does simulations because actually running the experiment is magnitudes more expensive and time consuming. See "Why software development is an engineering discipline" https://www.youtube.com/watch?v=zDEpeWQHtFU

TeMPOraL 9y ago
I agree. The primary thing distinguishing software development from other engineering fields is that the cost of building the product is essentially zero. Because building is what your compiler does. What a programmer does is design, and that is always influenced by the constraints of manufacturing - which, for software, are almost non-existent.