1. 6
  1.  

  2. 2

    It’s interesting to compare this piece with They Write the Right Stuff, which seems to draw exactly the opposite conclusions (albeit in very different problem domains)

    1. 2

      It would be great to see a cost comparison between the approach taken for shuttle software and the “normal” approach to software development for projects of comparable size. Sure, it’s wonderful that the shuttle software team did continuous process improvement, root cause analysis and so on, but what does it mean in terms of costs and timeframes?

      1. 5

        Perhaps it just means that software is difficult and expensive to write properly? It wouldn’t be the only engineering discipline with those characteristics.

        1. 1

          It’s definitely difficult and expensive, but I don’t think it means that we should just say “the shuttle team has the only correct approach, let’s write all software like that”, at least not without comparing the overall costs of different approaches.

          Sure, buggy software sucks, but it could still be a net benefit compared to non-buggy software which costs 10x more and takes 10x as long to start being useful. And I’m saying that as a person who’s really, really unhappy about the horrible unreliability of software.

    2. 1

      Given how bug-ridden and shitty most software is (and I’m including both open source and closed/proprietary here), I totally disagree that “software engineering is an idea whose time has come and gone”. I agree with the sentiment that one doesn’t need to obsess over metrics, but metrics are like any other tool - useful when used properly, but not a panacea.

      If anything, I think certain techniques which fall under the overall rubric of “software engineering” deserve more widespread usage: static code analysis, formal method / formal code verification, and - yes - metrics concerning code complexity. Software Engineering doesn’t need to go away, it just needs to evolve and improve. If it stays stuck in 1982, then sure, it’s going to fail to be useful. But there’s no reason for Software Engineering circa 2015 to look identical to Software Engineering circa 1982.