What is an “engineering mindset?” I have a very specific understanding of what I think engineering means.
I learned a lot from Juval at the Architect’s Master Class (AMC) but MOST of what we do, as Juval rightly points out in the AMC, is the construction phase, not the engineering phase. We do (classically) both wrong, but if we are to add an “engineering mindset” I think we need to be clear about what that is.
Some suggests that: “Scientists collect data. Engineers deal with constraints and realities.”
Tha’s a bit too vague for me so I’m going to says that a basic definition of engineering is:
>Engineering is the application of science.
That’s a bit vague, but I think it’s something we can work with and drill in on.
What’s this mean? It means that engineers are not scientists. It means they apply what science has learned, but since the engineers are not scientist, they must have a way to apply those “constraints” and the science data to the application at hand. I hope we agree on this as it’s my premise.
Because (at least in the western world) engineering is a profession, it has laws (licenses) and codes of professional conduct. With those codes of conduct come a “standard of practice” for most of the well established engineering disciplines. This means that a mechanical engineer working in industry “a” can also find a job as a mechanical engineer in industry “b” because the expectations for such an engineer are well understood.
To vastly over simplify, the way that engineering is practiced is that architects (and often the engineers) create a design to solve a problem. Then they work to create a set of blueprints for the construction of that design. The blueprints include a list of materials and their specifications and often the calculations showing why a particular component was chosen (for a particular load bearing piece, or some performance metric, etc).
Basically, the engineers do this by deciding what components they want to use (pipes, bolts, circuits, beams, conduits, ducts, etc) then checking the published specifications on those components to ensure they can handle the calculated constraints.
So therein lays our problem. We basically don’t have any of those things.
We have few components. The components we have are accompanied by super crappy specifications when they exist at all, and we have no (little) idea in advance of what range of load our components will be placed under.
It’s just really really hard to apply an engineering mindset to software.
At one point in the AMC, at least the one I attended, Juval says this. He sort of sighed, then gave one of his classic speeches about how we “still have to do better.” In that speech he says, “as much as we want this to be about engineering, at this point it’s still all about being a craftsman.”
So, Parnas is that middle ground between the hackers that are the 99%, and where you and I want to be which is just edged the tiniest bit toward an engineering mindset.
In the AMC Juval shows the design phase, which I mentioned the engineer does with the architect in a standard engineering practice. But it’s the design phase, not the engineering phase. You can think of it as “you build a design then validate it via the engineering.”
Juval discusses almost NO engineering. It’s just very difficult in software, which is why I’m curious what you meant by “building an engineering mindset.” I don’t know how to do that. At the moment I would be a lot happier if we were much better craftsmen. I think I know how to do that. And I believe this is what Parnas means.
It’s worth mentioning why I posted the link to the specific Parnas video I did (https://vimeo.com/10556923). It’s because it was about creating specifications (precise documentation written before the software).
If engineering is applying components that meet the specifications then we’ve moved in the right direction. I don’t think we could say that our current definition of a software specification comes from any application of science data, so I still don’t think coding to our crappy specs is actual engineering — but it’s at least an homage or mimicking engineering.
Software specifications tend to be one-offs for a very particular solution to a very particular business situation. That makes them utterly devoid of science, but hey, that’s where we are at the moment. Still, the closer we get to components built in a functional manner (but not via functional decomposition) then the closer we can inch toward engineering.
The work of Parnas, as described in that video, mentions TLA+ and the work of Leslie Lamport, who I’ve mentioned before. TLA+ is a method for using mathematics to describe functional algorithms as specifications, these models of the algorithm can then be tested via the model checked. The model checker is then generating the missing scientific data for the specification to prove (or not) that the algorithm actually accomplishes it’s goal (that the component can satisfy the constraints).
So, when you say you want to “build an engineering mindset” I hope that you’re talking about designing a system from components that we know satisfy their algorithms because we have tests to prove it (generating scientific data [aka: repeatable assertions]) and that we know the algorithms satisfy the design because we modeled them in the mathematics of TLA+, then tested the model against our inputs with the TLA+ model checker and found them to meet the constraints. The rest of the testing is the UAT testing by the customer revealing whether the output of engineering+construction satisfies their constraints.
