There are a bunch of cool things here, so I’m going to pick on the one that I kind of disagree with largely because I don’t have much to add to the other ones :-).
I think people from other fields tend to underestimate not just the importance, but the difficulty of reading blueprints just as much as non-technical people in the computer industry misunderstand the importance and difficulty of reading code. Specifically, this
Blueprints work because humans find it relatively easy to map them to their existing, shared, knowledge of real-world structures. The problem for software, as we saw earlier, is that there is no existing real-world structure we can map a software “blueprint” too [5].
does not match my experience with reading blueprints at all :-).
I have formal engineering education (EE, specifically) and I can read both electrical schematics and, owing to teenage stubborness, some mechanical blueprints (think assembly blueprints for motors and switchgear). If you give me a civil engineer’s blueprints to read, I’m maybe going to be able to tell you if that’s supposed to be a bridge or a shed by looking at the cover sheet and the site plan, but that’s about it. In fact, because my education is not in that particular field of EE, I’d have some trouble reading electrical blueprints for a building. As for everything else (mechanical/plumbing, most structural/truss diagrams etc.), haha, no. Even when I’m able to tell you what I’m looking at and map it to a real-world shape before me, much, if not most of the information that the blueprint conveys is lost on me. I’m not even able to articulate most of it. I guarantee many of the things a civil engineer can read off a blueprint are things you and me don’t even know are things that have names.
I’m going to explain that in terms of circuit schematics because I’m more familiar with them – I’m sure it’s kind of the same for civil engineers but I don’t trust things that move or deform :-) so I have very little experience with their stuff.
There are two levels to reading a schematic which, for the lack of a better term, I’m going to call “topological” and “idiomatic”. The former is basically what you think when you see one – which part connects to which other part and some details about how. That looks like what the engineering is about, but it’s not, that’s just a glorified puzzle map. The latter is where the real meat and bones are, and has to do with things like recognizing signal/information flow, recognizing higher-level circuit structures (filters, current sources etc.), understanding how different modules are isolated and what kind of second-order effects they might have or what interference they would be susceptible to, understanding the role of each module in a multiple-sheet schematic and so on. It’s where much of the “why” of a design resides, or rather, where much of it is definitively represented.
Teaching someone to read lumped-element circuit schematics “topologically” is straightforward enough, you can teach it to middle/secondary schoolers. It takes some mental effort to match some things on the schematic to real-world devices, like the pins on an IC or the terminals on a transistor, but that’s pretty much all there is to it.
Teaching someone to read the topology of circuit schematics for, erm, weirder structures, like RF or powerline structures, or integrated circuits, tends to be more difficult, and is generally impossible without specialized knowledge, especially when it comes to things like functional/equivalent schematics, which are meant to illustrate how something works, rather than how it’s put together. E.g. sometimes you include inductors or capacitors that aren’t physically there, it’s just how you model some capacitive or inductive effects, or you see a network of impedances that’s actually just a long piece of cable.
As for teaching someone to read idioms off of schematics, that’s one of the reasons why we send people to engineering schools in the first place. It takes years to build that skill, and it’s a skillset that’s sufficiently “soft” and hard to define that people mostly have to pick it up, because a “drawing and reading schematics” course is, at once, so focused and so abstract that it’s completely unrewarding. It takes years of industry practice to learn how to do it right. Hell, I suck at it, primarily because EE was mostly another angle at embedded development for me, so I never got enough actual electrical engineering experience to do it well. Fresh graduates score their first job after four years of reading more schematics than social media chatter and you still have to teach them how to read schematics.
There are plenty of things to say about UML and about why it failed to gain traction, but IMHO the idea that blueprints for technical structures are somehow easier to read (for actual engineering values of “read”) than blueprints for programs is, at best, an oversimplification.
The use of blueprints and schematics isn’t limited to fields where they’re closely-matched to real-world shape and placement – case in point, I think about half of the schematics I can draw from memory are for circuits that literally don’t exist, they’re things like equivalent models for interconnects or various active devices – and it works just as well. And reading them in a way that allows you to make informed engineering decisions is a skill that’s not easily-acquired, not easy to teach, takes years of practice to develop, and requires relating what you read to think that most people don’t even know they exist.
Schematics describe how the circuit comes together but in order to “read” how it works, you have to supplement that with an understanding of how the individual components and some “standard” structures work. It’s not a high-level/low-level thing – if you don’t know what the little pieces do you literally can’t figure out what the circuit does, either, and explaining it in simple language tends to make it worse, not better.
Specs change all the time (and schematics along with them) but schematics are generally drawn when a set of critical specs have been agreed upon, even with the understanding that they might change. Nobody starts drawing a schematic if they know for a fact that they can’t finish it because there’s going to be a big question mark in the middle.
Schematics are only part of the body of information that explains how something works and how (and why!) it was put together. They look like the closest analogy to code but they’re really nothing like one another, not just in terms of how and what they describe but in terms of purpose, too, and in terms of their role within an engineering organisation.
Probably the biggest thing is what you’ve mentioned though – schematics aren’t what’s implemented.
I challenge the circular specification notion. I think it’s very clear that a layer of abstraction exists above the code. As evidence, go up to someone in your sales department and ask a question about a specific feature. They will certainly not use words like “Kubernetes” or “JSON.”
Yet they still have words and concepts for describing the functionality.
I know I am missing nuance but I don’t think it’s unreasonable to say that frameworks solve some of those blueprint functions.
At least in some domains you can ignore the “architecture”, a whole lot of complicated problems go away, and sometimes (think CRUD website) you can hand the implementation to a beginner and they won’t mess up the hard parts of the problem if they stay within the guide.
Where my analogy falls flat is that you not only get the “blueprint” how it should look, but you also get the prefab pieces.
Many details will be trivial (wall colours, door knob styles, etc.)
Can’t speak with authority but I don’t agree that all details are trivial. Imagine a sports stadium and they put in a floor and lines in the wrong color, so it’s not up to the standards of the governing body. It’s a contrived example but I suppose there are more. A building plan will maybe not mention that the wall is a green screen wall, etc.
There are a bunch of cool things here, so I’m going to pick on the one that I kind of disagree with largely because I don’t have much to add to the other ones :-).
I think people from other fields tend to underestimate not just the importance, but the difficulty of reading blueprints just as much as non-technical people in the computer industry misunderstand the importance and difficulty of reading code. Specifically, this
does not match my experience with reading blueprints at all :-).
I have formal engineering education (EE, specifically) and I can read both electrical schematics and, owing to teenage stubborness, some mechanical blueprints (think assembly blueprints for motors and switchgear). If you give me a civil engineer’s blueprints to read, I’m maybe going to be able to tell you if that’s supposed to be a bridge or a shed by looking at the cover sheet and the site plan, but that’s about it. In fact, because my education is not in that particular field of EE, I’d have some trouble reading electrical blueprints for a building. As for everything else (mechanical/plumbing, most structural/truss diagrams etc.), haha, no. Even when I’m able to tell you what I’m looking at and map it to a real-world shape before me, much, if not most of the information that the blueprint conveys is lost on me. I’m not even able to articulate most of it. I guarantee many of the things a civil engineer can read off a blueprint are things you and me don’t even know are things that have names.
I’m going to explain that in terms of circuit schematics because I’m more familiar with them – I’m sure it’s kind of the same for civil engineers but I don’t trust things that move or deform :-) so I have very little experience with their stuff.
There are two levels to reading a schematic which, for the lack of a better term, I’m going to call “topological” and “idiomatic”. The former is basically what you think when you see one – which part connects to which other part and some details about how. That looks like what the engineering is about, but it’s not, that’s just a glorified puzzle map. The latter is where the real meat and bones are, and has to do with things like recognizing signal/information flow, recognizing higher-level circuit structures (filters, current sources etc.), understanding how different modules are isolated and what kind of second-order effects they might have or what interference they would be susceptible to, understanding the role of each module in a multiple-sheet schematic and so on. It’s where much of the “why” of a design resides, or rather, where much of it is definitively represented.
Teaching someone to read lumped-element circuit schematics “topologically” is straightforward enough, you can teach it to middle/secondary schoolers. It takes some mental effort to match some things on the schematic to real-world devices, like the pins on an IC or the terminals on a transistor, but that’s pretty much all there is to it.
Teaching someone to read the topology of circuit schematics for, erm, weirder structures, like RF or powerline structures, or integrated circuits, tends to be more difficult, and is generally impossible without specialized knowledge, especially when it comes to things like functional/equivalent schematics, which are meant to illustrate how something works, rather than how it’s put together. E.g. sometimes you include inductors or capacitors that aren’t physically there, it’s just how you model some capacitive or inductive effects, or you see a network of impedances that’s actually just a long piece of cable.
As for teaching someone to read idioms off of schematics, that’s one of the reasons why we send people to engineering schools in the first place. It takes years to build that skill, and it’s a skillset that’s sufficiently “soft” and hard to define that people mostly have to pick it up, because a “drawing and reading schematics” course is, at once, so focused and so abstract that it’s completely unrewarding. It takes years of industry practice to learn how to do it right. Hell, I suck at it, primarily because EE was mostly another angle at embedded development for me, so I never got enough actual electrical engineering experience to do it well. Fresh graduates score their first job after four years of reading more schematics than social media chatter and you still have to teach them how to read schematics.
There are plenty of things to say about UML and about why it failed to gain traction, but IMHO the idea that blueprints for technical structures are somehow easier to read (for actual engineering values of “read”) than blueprints for programs is, at best, an oversimplification.
The use of blueprints and schematics isn’t limited to fields where they’re closely-matched to real-world shape and placement – case in point, I think about half of the schematics I can draw from memory are for circuits that literally don’t exist, they’re things like equivalent models for interconnects or various active devices – and it works just as well. And reading them in a way that allows you to make informed engineering decisions is a skill that’s not easily-acquired, not easy to teach, takes years of practice to develop, and requires relating what you read to think that most people don’t even know they exist.
That but also.
The blueprints and schematics are not static, nor are they what is implemented. You get revision of them even after release.
Totally! And not just that:
Probably the biggest thing is what you’ve mentioned though – schematics aren’t what’s implemented.
I challenge the circular specification notion. I think it’s very clear that a layer of abstraction exists above the code. As evidence, go up to someone in your sales department and ask a question about a specific feature. They will certainly not use words like “Kubernetes” or “JSON.”
Yet they still have words and concepts for describing the functionality.
I know I am missing nuance but I don’t think it’s unreasonable to say that frameworks solve some of those blueprint functions.
At least in some domains you can ignore the “architecture”, a whole lot of complicated problems go away, and sometimes (think CRUD website) you can hand the implementation to a beginner and they won’t mess up the hard parts of the problem if they stay within the guide.
Where my analogy falls flat is that you not only get the “blueprint” how it should look, but you also get the prefab pieces.
Can’t speak with authority but I don’t agree that all details are trivial. Imagine a sports stadium and they put in a floor and lines in the wrong color, so it’s not up to the standards of the governing body. It’s a contrived example but I suppose there are more. A building plan will maybe not mention that the wall is a green screen wall, etc.