Explaining Software Systems Design To An Industrial Systems Designer

There is a superficial similarity between the jobs of a software and industrial systems designer but it disappears when you look closer than a job advertisement because the software systems designers are just going through the motions of their industrial brothers. What you have to appreciate is that three key elements are radically different in the software developer's environment.

Let me start by pointing to an advertisement for a software development company. It's obvious that EDS is quite proud of what they do. It's equally obvious that you as an industrial systems designer can see, or vividly imagine, the uncomfortable and horrified looks of EDS customers. You might want to think about what it says that EDS is proud of working in ways that would terrify any remotely sane person. I see in them complete disconnection from reality, from their customers' needs, and also from any kind of personal emotional health.

Inadequate Tools

Firstly, the tools are all inadequate and there is no objective way of measuring their inadequacies. If one of your machine tools blew up once a year killing its operator, this would be obvious and measurable. Similarly if it emitted noxious gases through 10 different ports resulting in either lots of tubes going out of it or workers choking to death on the factory floor. Similarly if it took up 20 times the volume allocated to the entire factory or turned its input into slag.

The equivalents in software are never obvious and rarely measurable. The only thing that's ever obvious in software is when your tool causes a nuclear explosion the moment it's turned on. Or completely fails to do anything at all. Your software tool merely turning half of itself to slag the moment you turn it on isn't obvious. And come to think of it, your software tool completely failing to do anything at all is only usually obvious.

Destructive Traditions

Secondly, it's traditional for the customers to provide not just worthless but actively destructive specs. Have you ever had a customer demand that all of the tools you use be branded Braun? In the software world, they do this as a matter of course.

Customers hire a software consultant to create a spec because they don't trust the programmers they're going to contract with. And they are correct since programmers are egotistical pricks uncaring of customers OR users. Well the problem with that is the consultant is just another programmer (a machinist) so he's incompetent at any kind of design. So the very first thing he specifies is the programming language that'll have to be used. Usually this is C++ or Java because they are mainstream.

This is the equivalent of specifying that you are going to buy all your parts from Canadian Tire. Because it's mainstream. And because finding people to service the parts from Canadian Tire will be easy. I am not exaggerating, this is word for word their rationale.

They are not concerned that the parts are low quality. They are not concerned that the parts will break down because they aren't durable. Or that they have a terrible MTBF. They are not concerned that using these parts will make the machine more expensive. They are not concerned that neither systems designers nor machinists (programmers) WANT to work with these parts because they are terrible, hard to work with, and break your fingers.

No, the only thing that matters is that they come from Canadian Tire because everyone uses Canadian Tire (so it must be good!) and Canadian Tire is mainstream. Again, I am not exaggerating in any way, shape or form as I believe my analogy is exact.

Recall the first point above, there is no objective (let alone obvious) way of measuring the inadequacy of any software tools or parts. Thus, the customers demand the parts be from a popular store. You certainly can't be trusted to decide what tools and parts you want to use!

Malleable Reality

Thirdly, software is made of pure information which unlike matter is infinitely malleable. Software is also a lot more complex (which feeds into point #1 above, making errors undetectable). Let me put it this way. Physical matter occupies only 3 spatial dimensions, yes? Software occupies N dimensions where N is variable and ill-defined. And if you understand the term 'race condition' then you know that's not a happy thing.

Also, with physical matter you only deal with a small finite number of interactions. Heat flow, friction, momentum and impulse, compression, tension, shear, viscosity, chemical reactions, electric and magnetic forces, optical and sound waves. With software, you define interactions out of your own imagination. And if programmers have agreed to operate in a consensus reality with a set number of interactions, this is just convention. Or I should say conventions PLURAL because I know of at least three mutually inconsistent sets of conventions (Imperative, OO, Functional) in widespread use.

(Going back to point #2, can you imagine being told "Today you will be using the following laws of physics. I know literally nobody likes these laws and you personally hate them because you think they make terrible machines. but they are the Industry Standard and so that's what you'll be using. Just be appreciative of how much better they are than the Industry Standard of 10 years ago!")

Now, consider how your job as an industrial systems designer would proceed if you could decide to change the laws of physics your machine operates on. Or you could decide to build machines that operate on multiple mutually inconsistent laws of physics (which is what C++ is by the way). So a guy comes up to you and says "we want a machine that makes cars, here's the spec of the cars we want and the volume the machine must take and the input it can take per car" but YOU have the power to change the laws of physics so they were anti-gravity cars capable of space travel. The problem you see is that the customer simply isn't capable of even IMAGINING what you can do.

Your Customers

So the customers you actually get fall into two categories. Customers with very narrowly defined needs who want cars that ONLY travel on the ground on LEGALLY DEFINED roads and cannot fly and cannot teleport and aren't bigger on the inside! And then you've got more typical customers.

Those are the customers who come up to you on the first day with a request asking for a car. Then the second day they tell you it'd be a great thing if it could fly. And on the third day they ask you if you can make it teleport home when they're done with it so they can save on parking. Which of course you CAN since all you have to do is jack in a guild navigator hopped up on spice melange to it. And the guild navigator isn't a problem because you can make it bigger on the inside.

Unfortunately, those aren't the only customers you get. Quite often you get bitchy customers who insist on a narrowly defined set of requirements. And the next day they insist on adding to the requirements so the car can fly. But all this time they insist you ONLY have the system do what THEY want. So basically they're your typical fascistic micro-managers except they don't have the common sense to realize micro-management is wrong and will ruin your work.

If you're a great systems designer and you kept in mind the need to BE FLEXIBLE from the get go (after having double-checked that your project isn't one of those very few with very narrowly defined needs, of course) then the very best customers are those who are laid back and don't give you any requirements beyond "automate what we're doing" or even better "help us do our job". They let YOU figure out what THEY need. Those are great customers and the products you come up with their help are fucking awesome.

Not nearly as good are customers that give you a sheet of requirements but don't look too closely when you throw it away. Those are problem customers because they make it difficult for you to figure out what their real requirements are because you can't admit to them that what they gave you is useless and you barely glanced at it.

The customers that try to pretend you're an industrial systems designer and they can give you a full set of requirements when they patently can't ... well they're the ones that make the job of software systems design hell on earth.

Conclusion

In summary, being a software systems designer means you can warp the laws of physics more easily than God but the only machine parts and tools that have ever been created all have sensitive spots that cause nuclear explosions if you touch them. If you're extremely competent then you'll pick unusually durable machine tools and parts that have extremely small nuclear triggers. Assuming your customers will let you since most of them insist you buy everything from Canadian Tire.

So yes most so-called "software systems designers" (by title) do the exact same tasks that you do. But with none of the same constraints and none of the same results because they operate in a radically different environment. And often they don't really care about that because they see YOU doing a GREAT job in the industrial sector so they think they can copy your success by going through the same motions. Kinda like Vanuatu tribesmen inviting cargo planes to return by building bamboo control towers.

So getting back to those copious ads you see for "software systems designers". If you examine them very closely I'll bet you'll find stuff like "must have 5 years experience in Java Enterprise" which translated means "must have 5 years experience shopping at Canadian Tire". Now consider what such an advertisement means for 1) the employer that put up the job posting, 2) what the actual job is going to be like, and 3) the kind of person that's going to be attracted to such an ad. Because I can tell you that such ads turn me completely off so my guess is they're looking for a skilled yet unusually arrogant & outspoken machinist to represent them to customers.