3 ms·

What I object to here is the core principle that there's something to fix in software development terms here. There's not. We've got robust, reliable tools for

What I object to here is the core principle that there's something to fix in software development terms here. There's not. We've got robust, reliable tools for creating nearly bug-free software. We have the usual engineering principles; we have automated testing; we have virtual machines and documented environments and specifications and APIs and all the rest. The problem is, there is a cost associated with preventing software bugs, and it's a big one. There's a reason Facebook kept saying "move fast and break things" - their software was buggy as shit, but the cost of that was minimal; in situations where bugs don't matter as much, time invested in robust bug-free software is an undesirable expense. In the Heartbleed case, this is reversed. There's a highly-sensitive, critical bit of Internet infrastructure; there have been minimal resources invested into it, but it is relied on by a lot of key systems. So the problem is a "social" one, in a sense. OpenSSL as a project did not invest enough in reducing the occurrence of bugs, and this resulted in the vulnerability. It's not the maintainers' fault, really; it was irresponsible for so many of us to rely on the software without considering it's quality. I suspect we'll start seeing renewed focus on bits of important software like OpenSSL, and greater attention to the engineering tradeoffs. So there's an upside to the whole thing...

gcv 13y ago
> We have the usual engineering principles No. We don't. As Alan Kay said, programmers don't have a solid concept like an arch to build on. In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. (And don't fool yourself into thinking that static analysis catches all these errors.) It has become fashionable to say that automated tests somehow turn programming into a rigorous discipline. This is bullshit. Tests are a decent band-aid which kinda help sometimes if you spend half your programming time writing them. And will still miss plenty of horrible bugs. In truth, programming remains a poorly-understood endeavor. Checklists as auto-written automatic tests might actually be a step in the right direction, especially if compilers start to analyze the kinds of mistakes individual programmers tend to make.
- derefr 13y ago
  > In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. In real engineering, you design things to be built out of a whole bunch of tiny, redundant components, each of which might or might not fail catastrophically with a given probability, but where the failure of any given component won't bring down anything else. You also source your components such that the failure of one component won't increase the likelihood of a global failure of all instances of that component in your design--you don't get all your rivets from the same manufacturing batch, etc. So, if we wanted to do software engineering the way we did other kinds of engineering, we'd have to have our computer systems resemble the physical, componentized systems that engineering principles actually apply to. I think this would involve, at least, two things: 1. Building only tiny components that could fail/crash without bringing down the entire project. Most usually, this is accomplished by separating the components into independent networked services. 2. Building several independent implementations of each component, and multiplexing requests to them using worker-pools (with client retry) and quorum-agreement protocols.
  - jboy55 13y ago
    I was trying to think of what in software is the equivilent as a 'rivet'. Something small, with a near singular purpose, one who's design has changed relatively little in decades. The only thing I could argue we have in software engineering is perhaps machine operands. For example, just about every processor will have a register and can a operand that will increment that register by one. The result of this is that most software projects are as complex as the most advanced 'real engineered' projects. As software engineers we design whole "space shuttles" in a month. The 'buggyness' of software engineering compared to 'real engineering' is the manifestation of the complexity of what software engineering does. The tools and processes of 'real engineer' are completely ill-adapted to the rapid development of the massive levels of complexity that is software. However, there are certain projects where a developer examines every instruction, at the detail that the 'real engineering' principles can help, however, the tools at the forefront in software engineering enable the addition of billions of washers to billions of rivets in days if not hours of design.

gcv 13y ago

> We have the usual engineering principles No. We don't. As Alan Kay said, programmers don't have a solid concept like an arch to build on. In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. (And don't fool yourself into thinking that static analysis catches all these errors.) It has become fashionable to say that automated tests somehow turn programming into a rigorous discipline. This is bullshit. Tests are a decent band-aid which kinda help sometimes if you spend half your programming time writing them. And will still miss plenty of horrible bugs. In truth, programming remains a poorly-understood endeavor. Checklists as auto-written automatic tests might actually be a step in the right direction, especially if compilers start to analyze the kinds of mistakes individual programmers tend to make.

derefr 13y ago
> In real engineering, when you build a bridge, a single rusty rivet won't cause it to fall down. In software, a single pair of misplaced braces give you critical "goto fail" bugs. In real engineering, you design things to be built out of a whole bunch of tiny, redundant components, each of which might or might not fail catastrophically with a given probability, but where the failure of any given component won't bring down anything else. You also source your components such that the failure of one component won't increase the likelihood of a global failure of all instances of that component in your design--you don't get all your rivets from the same manufacturing batch, etc. So, if we wanted to do software engineering the way we did other kinds of engineering, we'd have to have our computer systems resemble the physical, componentized systems that engineering principles actually apply to. I think this would involve, at least, two things: 1. Building only tiny components that could fail/crash without bringing down the entire project. Most usually, this is accomplished by separating the components into independent networked services. 2. Building several independent implementations of each component, and multiplexing requests to them using worker-pools (with client retry) and quorum-agreement protocols.
- jboy55 13y ago
  I was trying to think of what in software is the equivilent as a 'rivet'. Something small, with a near singular purpose, one who's design has changed relatively little in decades. The only thing I could argue we have in software engineering is perhaps machine operands. For example, just about every processor will have a register and can a operand that will increment that register by one. The result of this is that most software projects are as complex as the most advanced 'real engineered' projects. As software engineers we design whole "space shuttles" in a month. The 'buggyness' of software engineering compared to 'real engineering' is the manifestation of the complexity of what software engineering does. The tools and processes of 'real engineer' are completely ill-adapted to the rapid development of the massive levels of complexity that is software. However, there are certain projects where a developer examines every instruction, at the detail that the 'real engineering' principles can help, however, the tools at the forefront in software engineering enable the addition of billions of washers to billions of rivets in days if not hours of design.