4 ms·

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big part of why we're able to design extremely precise machines (the author worked on a lathe used for machining optical parts for the National Ignition Facility) is because we can characterize exactly where errors will come from (e.g. structure isn't rigid enough, temperature variation causes parts to expand by different amounts, parts not round or flat enough, etc.). Once we know what errors we need to control and their rough order of importance we can start improving the machine design to control them better. In theory, something similar could be done in software engineering (formal methods are part of this, but not a full solution). Rather than an error budget, you'd have some sort of bug budget, where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. I've never heard of anyone except Dan Bernstein[1] actually doing anything approximating this. Probably because the perceived level of effort is too high. I actually don't think it would take that much effort, but it would require quite a bit of organization to track where bugs are introduced and what their root causes are. This is probably why Bernstein, an individual, is able to do this, while no large team (that I'm aware of) has done anything similar. Of course, just like your toaster doesn't need to use precision machine design techniques (an over-engineered toaster is a bad toaster), most software doesn't need the effort/expense of a rigorous design process either, but some would benefit from it. [0]: https://dspace.mit.edu/handle/1721.1/9414 https://dspace.mit.edu/handle/1721.1/9414 [1]: https://cr.yp.to/djb.html https://cr.yp.to/djb.html

deleted 5y ago
[deleted]
ska 5y ago
> while no large team (that I'm aware of) has done anything similar. In areas like avionics, medical devices etc., there are formal production engineering methods applied to software as a matter of course. It can very work well, but it is definitely expensive compared to industry average.
- JimTheMan 5y ago
  I have my suspicion that medical devices aren't as rigidly programmed as the general public would like. Ie programmed by a biomedical/electrical engineer who isn't really a software specialist. But I'd be keen to hear from someone in the trenches.
  - ska 5y ago
    The industry changes slowly, and definitely regulators like the FDA were too hardware focused for a long time. Less so in the last 10-20 years. They've always been pretty good about critical systems but less so about "secondary" ones, and there are old devices out there where it shows. These days most of the industry has reasonable guidance and standards to follow. Characterizing "the industry" is hard; it includes cloud based data handling products and embedded devices with minimal software, etc. - a huge range. In both these areas (and others,to be sure), there is a formal engineering process that looks quite similar - and you need to embrace it in your software development or there will be a lot of friction. The goals of it are pretty sensible, but the approaches may seem odd to some with more mainstream software backgrounds.
  - zmmmmm 5y ago
    It's a different version of rigorous to what a normal software industry interpretation would be. It's about controlled processes, highly auditable, very sharply optimised focused managing the medical (and medico-legal) risk at the expense of every other type of problem. Generic software specialists I think actually aren't very good at it and take a while to acclimatise to it.
justicezyx 5y ago
I happened to also delved into machining tools and work as SWE full time. This comparison to me, is not workable between machine building and software. So the difference is that machines do simple things and not changing. But software do complicated things and always changing. You can easily understand which parts and/or ways of operating that cause machine misbehaving. Because you have full grasp of the parts and how they assembled and work But you cannot achieve the same for software, as each time it will be a new problem, or a new feature not working as expected. Actually, if you think a bit more, you might realize that we actually cares very little about the microscopic features of machines. For example, no one cares about screws, as long as they are machined according to spec, and torqued correctly during installation. The chance that a random screw to bring down a whole machine is close to zero. But any function in a software can bring down the whole software...
- lolinder 5y ago
  > For example, no one cares about screws, as long as they are machined according to spec, and torqued correctly during installation. The chance that a random screw to bring down a whole machine is close to zero. This sounds like people do care about screws. You identify two specific failure modes: they could be machined incorrectly, or they could be torqued incorrectly during installation. In either case, it is entirely possible that a single screw could cause the whole machine to fall apart (depending on which screw fails). Software is very similar. The smaller the function, the fewer things that could possibly go wrong (similar to a screw) but there's always the possibility that something goes wrong. Like screws, some functions won't do much harm if they're wrong, but some are keystones that, if they fail, will bring the whole thing down.
  - eschneider 5y ago
    Depending on your application, you learn to care very, very deeply about screws and bolts. Screw and bolt failures kill people, and they usually fail in conjunction with other design mistakes. Like software, it's not just one thing and you do need to sweat the details.
    - 5y ago
dangerlibrary 5y ago
The FoundationDB team took a different approach, that I found pretty interesting. They created a fully deterministic (single threaded) simulation of a distributed database, and then use that simulation to test their implementation of the database under difference scenarios. They'd probably be interested in something like what you describe, as the bulk of their work seems to be rooting out and squashing bugs caused by factors out of their control (dropped connections, etc.) https://www.youtube.com/watch?v=4fFDFbi3toc https://www.youtube.com/watch?v=4fFDFbi3toc
tephra 5y ago
I just finished Donald Knuth's "Literate programming" book and in there is one of the most wonderful papers I've read: "The errors of TeX". The version in the book goes up to 1991 but on ctan you should be able to find "errorlog.tex" if you want to read the updated (I think the last one is from this year) paper. Knuth has documented every bug and feature fix in TeX since its first version and categorised it into categories A-T.
shusson 5y ago
> It got me comparing precision machine design to software engineering. I think the problem is that the failure of physical systems are often caused by random failures, which can be tested for and probabilities determined e.g how long before a bolt breaks. This as opposed to software, which most often fail due to systematic errors and cannot be tested completely.
- jeffreyrogers 5y ago
  In precision machine design the failures are typically not statistical (like in fatigue failures) but due to errors of design. E.g. the tool spindle can maintain the desired tolerance when running from a cold start but after several minutes thermal effects cause it to be out of tolerance.
  - shusson 5y ago
    Yeah ok I did not know that, but compared to software it’s still practical to test the design for all known inputs.
indigochill 5y ago
It's also difficult because software despite being a realm of abstract constructs still exists in the physical world. Hardware corruption can introduce bugs despite the software being formally correct. It's fascinating learning about hardware manufacturing for satellites and needing to build in hardware redundancy and error checking for bits getting flipped by solar radiation. And of course there was the famous rowhammer attack. So you need not just software expertise but also hardware expertise if you're going to get serious about writing error-proof code, which Dan Bernstein happens to have.
snidane 5y ago
Software errors which are traceable usually get dealt with with ease. The remaining majority are unknown and governed by power law - eg. a bug uncovers a major redesign, but there is no time for rewrites so we have to roll along with it, complicating the design until next big rewrite if it ever happens. Power law phenomena are quantitatively untraceable. Averages mean nothing. Ergo software engineering is largely untraceable and better treated as a discovery or research process. To make things efficient, focus on removing impediments and continual simplification, but don't expect to predict much in advance. Unless it is an instance of a previous task, in which case why isn't there a function/library/framework for it yet?
- jeffreyrogers 5y ago
  This sort of thinking precludes the possibility of ever developing better methods though. And this statistical argument was actually quite common in machine design until people started actually building machines that were more precise than many believed possible. The thesis I linked has examples of arguments analogous to what you're saying for why precision machine design is impossible. Edit: I don't mean to be too harsh, you could be right, but software engineering is a young discipline. Mechanical engineering is much older and it was only recently that precision machine design became possible (and, just as importantly, teachable). I believe software engineering has the potential for a similar change in how it is done, at least for projects that warrant it.
stonemetal12 5y ago
> Rather than an error budget, you'd have some sort of bug budget, where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. Aren't we more or less doing that at the language level? C had lots of memory bugs, so C++ tried to fix it with collections, iterators, and smart pointers. It was still hard, so Java came along with GC and null ref exceptions. The situation was less bad, but multithreading became popular and Java didn't help as much as we would like so the Rust people gave it a go. Though I really do suggest trying it yourself. If you want to be a better programmer, developing a style that minimizes bugs you write is pretty much pure win.
- likeabbas 5y ago
  This would make sense if we migrated existing software projects to different languages.
jodrellblank 5y ago
> "where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. I've never heard of anyone except Dan Bernstein actually doing anything approximating this" Not sure if I completely understand but here[1] is a talk by Jules May called "If considered harmful: How to eradicate 95% of all your bugs in one simple step" where he discusses that they analyzed what was causing a lot of bugs in their programs, and found it was code which keeps state synchronised using `if` in far distant places in the codebase, many places with "if (stateFlag) {}" which then gradually fell out of sync with each other as people changed some but not all of them. By redesigning the programs so that instead of call points dotted around the codebase all saying `if (condition) { function1() } else { function2() }` they all say `obj.doWork()` any the condition checking code only exists in one place inside the class definition, the talk title claims they removed 95% of bugs in their codebase. Inside the talk he spends all the time explaining the idea and doesn't actually talk about the effect it had on their bug tracker database, bugs encountered, etc. which is a bit of a shame. Of course, the comments are suitably sneery for a programming talk: "having double checking being your main source of bugs means that you really try your best to write bad code. The whole talk boils down to: double checking conditions is bad and we found it 20 years after everybody else." - even if you agree with that, the analysis of their bug tracker to find what was causing most bugs and redesigning how they code based on that, appears to be an example of what you describe. [1] https://www.youtube.com/watch?v=z43bmaMwagI https://www.youtube.com/watch?v=z43bmaMwagI

deleted 5y ago

[deleted]

ska 5y ago

> while no large team (that I'm aware of) has done anything similar. In areas like avionics, medical devices etc., there are formal production engineering methods applied to software as a matter of course. It can very work well, but it is definitely expensive compared to industry average.

JimTheMan 5y ago
I have my suspicion that medical devices aren't as rigidly programmed as the general public would like. Ie programmed by a biomedical/electrical engineer who isn't really a software specialist. But I'd be keen to hear from someone in the trenches.
- ska 5y ago
  The industry changes slowly, and definitely regulators like the FDA were too hardware focused for a long time. Less so in the last 10-20 years. They've always been pretty good about critical systems but less so about "secondary" ones, and there are old devices out there where it shows. These days most of the industry has reasonable guidance and standards to follow. Characterizing "the industry" is hard; it includes cloud based data handling products and embedded devices with minimal software, etc. - a huge range. In both these areas (and others,to be sure), there is a formal engineering process that looks quite similar - and you need to embrace it in your software development or there will be a lot of friction. The goals of it are pretty sensible, but the approaches may seem odd to some with more mainstream software backgrounds.
- zmmmmm 5y ago
  It's a different version of rigorous to what a normal software industry interpretation would be. It's about controlled processes, highly auditable, very sharply optimised focused managing the medical (and medico-legal) risk at the expense of every other type of problem. Generic software specialists I think actually aren't very good at it and take a while to acclimatise to it.

justicezyx 5y ago

I happened to also delved into machining tools and work as SWE full time. This comparison to me, is not workable between machine building and software. So the difference is that machines do simple things and not changing. But software do complicated things and always changing. You can easily understand which parts and/or ways of operating that cause machine misbehaving. Because you have full grasp of the parts and how they assembled and work But you cannot achieve the same for software, as each time it will be a new problem, or a new feature not working as expected. Actually, if you think a bit more, you might realize that we actually cares very little about the microscopic features of machines. For example, no one cares about screws, as long as they are machined according to spec, and torqued correctly during installation. The chance that a random screw to bring down a whole machine is close to zero. But any function in a software can bring down the whole software...

lolinder 5y ago
> For example, no one cares about screws, as long as they are machined according to spec, and torqued correctly during installation. The chance that a random screw to bring down a whole machine is close to zero. This sounds like people do care about screws. You identify two specific failure modes: they could be machined incorrectly, or they could be torqued incorrectly during installation. In either case, it is entirely possible that a single screw could cause the whole machine to fall apart (depending on which screw fails). Software is very similar. The smaller the function, the fewer things that could possibly go wrong (similar to a screw) but there's always the possibility that something goes wrong. Like screws, some functions won't do much harm if they're wrong, but some are keystones that, if they fail, will bring the whole thing down.
- eschneider 5y ago
  Depending on your application, you learn to care very, very deeply about screws and bolts. Screw and bolt failures kill people, and they usually fail in conjunction with other design mistakes. Like software, it's not just one thing and you do need to sweat the details.
  - 5y ago

dangerlibrary 5y ago

The FoundationDB team took a different approach, that I found pretty interesting. They created a fully deterministic (single threaded) simulation of a distributed database, and then use that simulation to test their implementation of the database under difference scenarios. They'd probably be interested in something like what you describe, as the bulk of their work seems to be rooting out and squashing bugs caused by factors out of their control (dropped connections, etc.) https://www.youtube.com/watch?v=4fFDFbi3toc https://www.youtube.com/watch?v=4fFDFbi3toc

tephra 5y ago

I just finished Donald Knuth's "Literate programming" book and in there is one of the most wonderful papers I've read: "The errors of TeX". The version in the book goes up to 1991 but on ctan you should be able to find "errorlog.tex" if you want to read the updated (I think the last one is from this year) paper. Knuth has documented every bug and feature fix in TeX since its first version and categorised it into categories A-T.

shusson 5y ago

> It got me comparing precision machine design to software engineering. I think the problem is that the failure of physical systems are often caused by random failures, which can be tested for and probabilities determined e.g how long before a bolt breaks. This as opposed to software, which most often fail due to systematic errors and cannot be tested completely.

jeffreyrogers 5y ago
In precision machine design the failures are typically not statistical (like in fatigue failures) but due to errors of design. E.g. the tool spindle can maintain the desired tolerance when running from a cold start but after several minutes thermal effects cause it to be out of tolerance.
- shusson 5y ago
  Yeah ok I did not know that, but compared to software it’s still practical to test the design for all known inputs.

indigochill 5y ago

It's also difficult because software despite being a realm of abstract constructs still exists in the physical world. Hardware corruption can introduce bugs despite the software being formally correct. It's fascinating learning about hardware manufacturing for satellites and needing to build in hardware redundancy and error checking for bits getting flipped by solar radiation. And of course there was the famous rowhammer attack. So you need not just software expertise but also hardware expertise if you're going to get serious about writing error-proof code, which Dan Bernstein happens to have.

snidane 5y ago

Software errors which are traceable usually get dealt with with ease. The remaining majority are unknown and governed by power law - eg. a bug uncovers a major redesign, but there is no time for rewrites so we have to roll along with it, complicating the design until next big rewrite if it ever happens. Power law phenomena are quantitatively untraceable. Averages mean nothing. Ergo software engineering is largely untraceable and better treated as a discovery or research process. To make things efficient, focus on removing impediments and continual simplification, but don't expect to predict much in advance. Unless it is an instance of a previous task, in which case why isn't there a function/library/framework for it yet?

jeffreyrogers 5y ago
This sort of thinking precludes the possibility of ever developing better methods though. And this statistical argument was actually quite common in machine design until people started actually building machines that were more precise than many believed possible. The thesis I linked has examples of arguments analogous to what you're saying for why precision machine design is impossible. Edit: I don't mean to be too harsh, you could be right, but software engineering is a young discipline. Mechanical engineering is much older and it was only recently that precision machine design became possible (and, just as importantly, teachable). I believe software engineering has the potential for a similar change in how it is done, at least for projects that warrant it.

stonemetal12 5y ago

> Rather than an error budget, you'd have some sort of bug budget, where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. Aren't we more or less doing that at the language level? C had lots of memory bugs, so C++ tried to fix it with collections, iterators, and smart pointers. It was still hard, so Java came along with GC and null ref exceptions. The situation was less bad, but multithreading became popular and Java didn't help as much as we would like so the Rust people gave it a go. Though I really do suggest trying it yourself. If you want to be a better programmer, developing a style that minimizes bugs you write is pretty much pure win.

likeabbas 5y ago
This would make sense if we migrated existing software projects to different languages.

jodrellblank 5y ago

> "where you tracked what sort of bugs were caused by what sort of constructs, and design your program in such a way to minimize their chance of being introduced. I've never heard of anyone except Dan Bernstein actually doing anything approximating this" Not sure if I completely understand but here[1] is a talk by Jules May called "If considered harmful: How to eradicate 95% of all your bugs in one simple step" where he discusses that they analyzed what was causing a lot of bugs in their programs, and found it was code which keeps state synchronised using `if` in far distant places in the codebase, many places with "if (stateFlag) {}" which then gradually fell out of sync with each other as people changed some but not all of them. By redesigning the programs so that instead of call points dotted around the codebase all saying `if (condition) { function1() } else { function2() }` they all say `obj.doWork()` any the condition checking code only exists in one place inside the class definition, the talk title claims they removed 95% of bugs in their codebase. Inside the talk he spends all the time explaining the idea and doesn't actually talk about the effect it had on their bug tracker database, bugs encountered, etc. which is a bit of a shame. Of course, the comments are suitably sneery for a programming talk: "having double checking being your main source of bugs means that you really try your best to write bad code. The whole talk boils down to: double checking conditions is bad and we found it 20 years after everybody else." - even if you agree with that, the analysis of their bug tracker to find what was causing most bugs and redesigning how they code based on that, appears to be an example of what you describe. [1] https://www.youtube.com/watch?v=z43bmaMwagI https://www.youtube.com/watch?v=z43bmaMwagI