Writer and consultant on formal methods, testing and software correctness, author of Logic for Programmers and Practical TLA+. He ran the Crossover Project, interviewing seventeen people who worked as traditional engineers before becoming software developers, to settle by evidence whether software engineering is engineering.
We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.
Their wordsOf the 17 crossovers I talked to, 15 said yes.
Their wordsWe are separated from engineering by circumstance, not by essence, and we can choose to bridge that gap at will.
Their wordsI think this project and writing about it and thinking about it has firmly moved me from the camp of we are definitely not to we probably are.
Their wordsMuch of the engineering there is low-stakes, low-consequence, just like much software is.
Their wordslicenses exist because we are part of society and have legal requirements, not because they are essential to what it means to do engineering
Their wordsNone of the people arguing for or against software engineering as engineering have worked as engineers.
Their wordsAlmost everything we think is unique about software appears in every other field of engineering.
Their wordsTo assume that software is uniquely unpredictable is a special kind of arrogance.
Their wordsAnd the first thing he pointed out to me was that they had their Agile revolution in 1960.
Their wordsIf I had to summarize what I found in general, I'd put it like this. Everybody hates waterfall.
Their wordsWe can change software much faster than anybody else can change their systems.
Their wordswhile we are a lot better at iterating than other fields, we're worse at the planning part. Like we still need to do some kind of planning before we iterate and we just aren't as good as those other fields.
Mental modelFeedback loops
Their wordsThe core tension of engineering is between how expensive it is to make a mistake and how quickly you can iterate. The faster you can iterate, the less planning you need to do before you iterate, and the more expensive it is, the more planning you need to do.
Their wordsBut constraints in software tend to be soft constraints.
Their wordsSoftware is far more consistent than any other kind of engineering.
Their wordsRather than fix a trad issue with trad engineering, Boeing opted for the software kludge, and then people died.
Their wordsPlenty would kill to get the same kind of automated testing we treat as a given.
Their wordsYeah, I interviewed like 20 people on this. I think all 20 mentioned version control as the thing they wish they had in their old field.
Their wordsSoftware is kind of unique in having the third kind of the practitioner conference where we are just meeting to get better at what we do. We also are really the only kind to really focus heavily on like open source in making our knowledge freely available.
Their wordsAnd that kind of compiling of information about the materials is something other fields do that we don't do. An analogy that I would think of in software would be something like a 500-page book on how to version an API.
Their wordsBut this is the book that I give to every junior engineer because I think like nobody ever really talks about debugging as like a discipline outside of like basic heuristics.
Their wordsYou do not need full code verification to write good software or even to write near-perfect software.
Their wordsIn fact, the vast majority of distributed systems outages could have been prevented by slightly-more-comprehensive testing.
Their wordsmost people in high-assurance software don't use formal methods
Their wordsI love formal methods, but I think it's a fairly niche tool for most people and I think like property-based testing is in general going to be useful for more people.
Their wordsbut I can tell you with first hand experience nuclear power plants do not care about this stuff. They're actually just fine with with with thorough testing.
Their wordswhen you start talking about like most interesting domain problems, you have to pull in so much context that basically even writing what the function is supposed to do becomes a nightmare. The imperative program you write that will get correct 99% of the time is probably good enough to use in almost all cases.
Their wordsI think the case of TLA+ and most, not all, but most formal methods, they shine the most in highly computational domains, where most of the problems are highly technical and not like business embedded.
Their wordsFinding the right spec is one of the biggest challenges in formal methods.
Mental modelTrade-offs
Their wordsFormal verifiers have a dilemma: the more expressive the language, the harder it is to prove anything in it. But the less expressive the language, the harder it is to write anything in it.
Mental modelThe map is not the territory
Their wordsThen the actual system might still have bugs, but we can iron out the issues in the abstraction such that we don't actually build them in the real system.
Their wordsAnd often I found with my clients I have to tell them like it's doing a good job at generating the actual design, but in actually expressing what the design is supposed to do, it cannot do that yet. You have to do that part yourself.
Mental modelPositioning
Their wordsRather, the best way to reduce the volume and severity of mistakes is to adjust the system itself.
Their wordsBut unit tests don't give you much confidence in your code.
Their wordsUncle Bob gives terrible advice. Following it will make your code worse.
Their wordsJust because we use a different branch of math doesn't mean we're not doing engineering.
Their wordsAnd I wonder sometimes if that is the reason people don't recognize the use of math in software engineering is because the math they do need is not the math they've been exposed to.
Their wordsBut I think it is more useful for most developers to have an exposure to like what math has in the various fields versus just going all in every single field when they see them, right? You've got to know what's available to know what's most useful for you. And most math will not be useful for you.