The Economic Benefits Of Personal Computers

Some people (engineers and fascists, not that those two terms aren't almost synonymous) have difficulty grasping that modern personal computers have vastly increased productivity of individuals. They say correctly that big mainframes greatly helped the record-keeping of large corporations. And that smaller computers helped the lesser record-keeping of smaller corporations. And that's it, because individuals can't possibly be doing any record-keeping.

These people also get greatly upset over computer games and other modern "distractions" and are dismissive of the fact these things are more enriching and valuable than other equally mindless age-old pastimes of chatting over the water cooler, being brainwashed by the idiot box, square dancing, and bobbing for apples. Never mind those, age-old means traditional and there can't possibly be anything wrong with that! In fact, when people aren't slaving for a corporation they should just go to bed like the good slaves they are.

Never mind the benefits of automation. The order clerks that don't have to be paid for because web sites are processing their orders. The large retail warehouses (not a new phenomenon) where order pickers are aided by autonomous robots. The ATM machines everywhere. The self-checkout machines. Being able to do your banking and taxes online with the aid of software. No, we're not going to go into those. It's not like they greatly benefit individuals and the economy and are aided by small computers.

No, we will here talk about individual record-keeping. Because individuals DO in fact keep records. These are called "notes". And in the bad old days which the engineers are conveniently forgetting, individuals had to keep records ANYWAYS. They were just on this thing called "paper" which had no search functionality, random or fast lookup. In the bad old days, people used these things called "index cards" as meta-records. They were shit! In the bad old days, people did linear searches through all of their records instead of using 'grep' or 'google'.

People DID have records in the bad old days, and they DID engage in record-keeping. But in the bad old days, even though you could write at as much as 1/10th the speed of typing, getting writer's cramp a hundred times faster than RSI (and infinitely faster if you're smart enough to switch to Dvorak keymap and/or get a Kinesis keyboard). Hmm, a 10-fold productivity improvement you say? Nay! Because in the bad old days, retrieval of records was so difficult it was prohibitively expensive. Yea, in the bad old days, in order to be able to maintain any kind of records, you needed very high intelligence to remember where your records were.

And nowadays ... intelligence no longer matters. You want to remember something? Type it up. If you're moderately organized, you'll be able to remember it. So that nowadays, it's possible for someone to function with as low as 2 slots in working memory when people normally have 4, in other words at less than 50% capacity. You know those times when your head is fuzzy and you're braindead? Well, it's actually possible to measure numerically how far your mental capacity has gone down. And it no longer matters. Because you can still do productive work ... with your cybernetic memory.

Thanks to personal computers, everyone now has an IQ of roughly 150. An enormous boost to personal productivity and the economy. Sure, people aren't any more logical than they ever used to be, and they aren't any more creative than they used to be. But in terms of raw intelligence, raw memorization ability, the boost provided by computers is phenomenal!

Of course, none of that matters as individuals cannot possibly matter to slaves or insects. Which is what the typical engineer is.

And to think, this is all without the computer / Internet revolution having happened yet. Because it still hasn't. For all that you morons believe it's taken the world by storm, it is barely inching its way through the world. It still hasn't happened in any meaningful way as cybernetic memory (or dirt cheap social organization provided by the Internet) is nothing compared to what's coming.

Speaking of dirt cheap social organization provided by the Internet. That was pioneered by people illicitly sharing porn and movies. It took over two decades for business finance to move to take advantage of it. So no wonder fascists and engineers, to whom only corporations and governments could possibly matter, would be utterly blind to the phenomenon. After all, it's not like dirt cheap porn brings any value to anyone's life. Certainly not to someone who takes seriously the notion of sexual abstinence for adolescents.

Semco vs Toyota

I've just been rereading all about the Toyota Production System to contrast it with Semco SA when I was struck by the fascinating realization that in many important ways, they are total ideological opposites.

Similarities

Yes, both focus on the long term, on teams, on developing people, on mutual responsibility between workers and managers, and empowering workers so they have some means of directing their work. But concerning what it is these systems control and what they let workers decide, they are total opposites.

Oppositions

In Semco, the ONLY thing that matters is your output. Everything else is up to yourself and your team. In TPS, the only thing that matters is your INPUT, your effort and the ingenuity you put into the system in order to freely but continuously improve output.

In TPS, your workflow is very bureaucratically watched, though you are free to change it however you wish so long as it objectively 'reduces waste' (and you leave it in a state that those following you can learn from). But while output is meant to always improve (in quality or cost) this is NEVER predictable nor are there ever any specific expectations about it.

Both Semco and TPS micromanage ONE thing and systematically leave the other as a free variable. But what they choose to micromanage (micro-negotiate really) and what they choose to leave free are opposites.

Finally, TPS works in a constant state of crisis whereas Semco works in a constant state of relaxation. And Semco feels like totalitarian anarcho-communism whereas TPS feels like benevolent cooperative fascism.

Generalizations

What I really want to know is what I can learn about political systems design from this. It seems like there's a very important lesson here. My hypothesis so far is that you need to micro-manage either the input or the output and stay the fuck away from the other so the people involved don't feel like you're turning them into robots.

But does that mean you must micro-manage one side or the other in order to eliminate corruption? And is there another way of splitting freedom vs authoritarianism other than input vs output? I suspect no. More likely, have I gone off the rails somewhere?

Ah yes I have. Already I see that micro-manage isn't the right word. The right-word is micro-negotiate.

Are the political lessons learned from politico-industrial systems even applicable to other kinds of political systems? I would like to think so since politico-industrial systems are particularly harsh and unforgiving. But the industrial aspect introduces an external reality which most political systems lack. At least, political systems other than China since China's obsession with industrializing means that it is, essentially, just an industrial company.

I still don't fully understand why one variable has to be left totally free. But it probably has to do with keeping a psychological comfort zone for workers to retreat to. No, not quite. In Semco it provides such a comfort zone from the external requirements of output. In Toyota there is simply no external requirement and no comfort zone from it - everything is input, intrinsic, internalized. And that's all negotiated in what I see now as a creepy way since you're negotiating your ego.

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.