Hi Grady, I’ve been a big fan of your “on architecture” podcast.
Q. On system correctness - my education was in electronic engineering, rather than comp sci, so it’s very instinctive for me to test components as I go (before assembling a broken machine, and having to fault-find afterwards!) Recently I’ve read Eberhard Rechtin’s work (http://blog.mccormack.net.au/heuristics-for-testability), and honestly quite stunned by how much of this knowledge is not taught to software engineers. My favourite heuristics around system testability is “…for a system to meet its acceptance criteria to the satisfaction of all parties, it must be architected, designed and built to do so - no more and no less.” That has direct application today, in BDD, microservices and continuous delivery, but there are problems around concepts like progressive redesign in order to “build quality in”. I think many practitioners misunderstand “build quality in” to mean “write more unit tests”, rather than “modify the intrinsic system design in order to to eliminate classes of failure”, perhaps because they lack deeper training in systems architecture.
So, what should modern software engineering education be taking from more established engineering disciplines? It seems that many trivial correctness problems (for a well-structured monolith) are exacerbated by trends, e.g. microservices and the resulting distributed state machines.
Thanks!
Ken