Freesteel Blog » Food for thought

Food for thought

Saturday, November 16th, 2013 at 11:50 am Written by:

A lot’s been going on in the world. It’s out of my hands. I don’t know anything or have any influence over it, so what I say shouldn’t matter. Very sensitive. Yadda yadda. Got to watch out because it’s publicly listed companies and there’s shares and high-stakes gambling and all that money stuff.

Funnily enough, private non-listed companies that do not have any jittery share-holders or regulations to worry about are even more extremely secretive about their businesses. I wonder if they bother to invent positive and vaguely plausible excuses for their secrecy when there is apparently no commercial reason for it.

Secrecy is actually about power in all frames. This is the week that the TPP trade agreement got leaked. The text outlines a vast expansion of no-strings-attached corporate monopolies (aka “Intellectual Property”) in all sectors of the economy — policies that have been soundly and democratically rejected in the past. There’s no reason to keep that stuff secret, except in order to facilitate a plan to ram it through into law in an instant as a shock to the system in an opportune moment.

Not sure why I’m talking about that. I wanted to talk about food.

I’m thinking about the best food, the kind you get served at the very best restaurants.

There’s a secret that these gourmet restaurants understand about food. And this secret is that food is made on farms. That’s a fact. And the more layers and of commerce, transport, storage, refreezing, mislabeling, mixing, processing and bulk dealing that exist between where the food is made and where it is eaten, the lower the quality.

The really top restaurants will have formed a direct relationship with the farms on which their meat is reared. They might even know the name of the cow each steak came from. This goes both ways: if the farmer knows he has a buyer who really cares about the quality of the product, he’s going to make an effort to get it right, because he knows he is not wasting his time.

It is the same with software. Just as all food is made on the farm, all software is made by programmers. There is very little value that can be actually added by the intervening layers of business. The pixels on your screen, the interface, the bugs, the work flows you have to follow at the keyboard for six hours every day are entirely put there by us. So you’d think there’d be enough expert engineering users out there who could have formed direct relationships with the programmers of the software to have got an open source ecosystem off the ground around here.

Apparently not. It’s not that programmers don’t prefer to do open source. I sit in my shared office with my programming community feeling pretty envious of my peers who write operating systems, or compilers, or webservers, or browsers, or content management systems, or database systems who have all liberated themselves from the horrible wasteful closed source world where vast amounts of code is duplicated, and the fate of development is in the hands of disinterested businessmen who make money by limiting the access to the software as much as they can, and where quality rarely counts.

I mean, take two leading content management systems, Drupal and WordPress, for example. Which one of these is going to thrive and win out in the long term? No one knows. But what we do know is that the answer will depend only on the quality of the products — a combination of look, feel, implementation, ease of installation and user traction. It will have nothing to do with who owns them. In fact the public owns them. They are public software. Also, there is very little duplicated code between them. Both products share an absolutely identical core of systems made up of Apache, PHP and MySQL and a few other modules besides that are all extremely high-powered and free.

So anyway, it’s always been a mystery to me why engineering software has utterly failed to develop any ecosystem of open source products at all when it so badly needs it.

Imagine a really good FEA (Finite Element Analysis) solver that the industry could rely on to get the answers right.

Now, free software comes with absolutely no warrantee of fitness for purpose. But neither does any proprietary software, no matter how much money you’re forced to pay for it. So when your crane falls down because there was a bug in the stress simulation calculations, you can’t get any compensation from the software company. In fact, they don’t even have to acknowledge there’s a problem. And they won’t if they perceive it will harm their business, which of course it should. They have the absolute means to cover it up. Or better yet, completely ignore it. We’re so used to it we don’t even expect otherwise.

It’s amazing that engineering firms accept these terms and don’t require disclosure of the list of all known bugs and issues in the software they plan to use before they even consider evaluating it for purchase.

Think about it. If you’re concerned about the food in a restaurant and the restaurant proud of what they do, they’re usually pretty happy to give you a tour of the kitchen.

And when a company considers buying out another company, they send over the accountants and lawyers to have a good thorough root through all the books and records having agreed in writing that nothing will be kept back. It’s standard procedure.

Yet when it comes to buying software there is nothing equivalent undertaken by those who should be the most intelligent and high power users in the business.

Here is a story I’ve heard from the nuclear industry where it is very important that cranes do not collapse under load, since the consequences are more severe than simply killing a few on-site contractors. The regulators require the strength of the designs to be calculated by hand on paper because they have so little faith in the software. Sounds reasonable, doesn’t it? Sometimes it’s not even the crappy software. Remember the Pentium bug? Things crop up. Computer code can have failures.

Now, here’s the problem. Hand calculations are also unreliable. But for some reason mad-made mistakes in calculations are not perceived as being so severe. Maybe it’s because responsibility can be apportioned, and mistakes can be double-checked and corrected. Much as could be done if it was open source software!

However, when you detect and fix a mistake in the software you’re fixing it for thousands of instances, not just in one single hand calculation. Keep this in mind.

In order to eliminate hand calculation errors one would be wise to also run the calculation through the computer software in order to pick up anything stupid, like a typo. The answers should be identical.

So what happens if the hand calculation discovers an error in the software? After all, that’s why we’re doing the hand calculation in the first place — because we think there could be a bug and there will be no one to blame because it would be the computer’s fault. Is this not a worthy scenario?

Let’s remind ourselves: what happens if restaurant food makes you ill? You’ll probably never eat there again. Is this a sufficient response? Don’t you have a moral duty to report it to the authorities so they can send around an inspector to investigate and apply necessary measures to prevent any poisoning of people in the future.

Now what are you supposed to do when you find a mistake in some engineering software that a lot of other people are depending on to make cranes, some of which are not so safety critical as a nuclear crane, but which nevertheless can collapse and kill? Where is agency that takes a detailed interest in the quality of the software? We haven’t got one!

Why is engineering software a special failure? Why do all those other sectors of software (operating systems, databases, compilers, etc) seem to support a more or less dominant open source ecosystem that has freed itself from private control to pursue technical excellence without compromise?

It’s obvious. All these other sectors of software have sizable communities of users who are themselves computer programmers. They’re the only people who seem to know anything. The proportion of engineering software users who are computer programmers is almost exactly zero. Whereas the proportion of users who deal with operating systems who are also computer programmers is high enough to support the development of colossal GNU/Linux system in the first round.

What do computer programmers know about software that engineers don’t seem to understand?

Number 1. Software is written by computer programmers, not by corporations. Just as meat is made on farms, not in factories. The brand is bullshit.

Number 2. You have to seek out quality. It doesn’t come to you. If a company is screaming about how their software is the best in the world, it isn’t. Quality is modest, curious, tentative. It seeks out its own flaws, considers them, and can discuss them in light of the compromises that have been made in the design. It is genuine.

Number 3. Software should be paid for once — and then it’s free. Programmers, who are the only people who can make software, don’t get paid royalties.

This theory of the “ownership” of software derived from the creative arts.

The reason you feel good about paying more than the cost of the plastic CD for a piece of recorded music, say, is that you believe that some of that money is going to the artist. You like the song, you probably like the singer, and you feel good about rewarding them with some money. Why not? We can set aside the entire industry of crooks and scammers who notoriously intercept as much of the money as they can on its way from the customer to the artist, but this is the central premise, isn’t it? The proponents always come back to this, even as they claim with a straight face that a Copyright term should last 70 years beyond the death of the author. Hey, maybe his great grandchildren deserve to a few quid for a piece of ancient copied art that society had decided is of merit among all the other perfectly good stuff. Quite why, I don’t know. Authorship is not some kind of inherited title, like Marquis.

In software, none of the recurring money goes to the programmers. We’re paid once to write the software, and then the users pay over and over and over again every single year to someone who didn’t write the software.

Free software is efficient software because its deployment depends on technical considerations only. It’s like a road network without tolls where the choice of route depends only on the availability of roads, and nothing else. Somehow we manage to pay for loads of those tarmac and concrete strips to get built and no one complains. Software is just as much a piece of critical infrastructure as a bridge. No question about it.

At present I see very few routes to the establishment of a free software ecosystem in the engineering sector, even though it desperately needs it. There’s no evidence that the engineers will ever get it. The only hopes is from the Maker Movement where hackers, who are often computer programmers, are finally becoming users of engineering software. That’s the only way.

Another remedy is for programmers to start talking to one another between companies about technical things in order to start lifting the general understanding of software development so that there will eventually be some understanding in the sector.

I don’t know why it’s not a routine part of our culture, but it feels naughty. Corporate lawyers all get together at international conferences and swap stories and tricks of the trade. I imagine the accountants do about their international tax scams too. And it’s not like the bosses are keeping secrets about who they are planning to promote, boy-out or lay-off. So why can’t we have secrets too?

Where are the meetings for engineering software programmers where we get to discuss how we move things forward? Questions like: has anyone managed to reverse engineer the ACIS file format? How much luck are we having making use of OpenCL? When are we going to find someone who understands how to make a good surface triangulator? And what’s the next generation of solid modelling kernel going to look like?

Maybe these chit-chats have got to happen informally through back channels of emails and private news groups, puzzle challenges, hack-days, before it becomes official. It’s an idea.

Don’t fergodsake ask permission from your boss before commencing such chit-chats. The answer will be No, won’t it? You know that.

It’s nothing to do with corporate competition and technical trade secrets, because the answer will be No even for chit-chat between programmers in the same goddamn company. Here’s why.

Suppose a programmer on Team X finds out that they have some pretty handy modules that would be useful to the work of Team Y. Team Y is in the same company, so helping out Team Y is going to move the whole company forward. However, doing so will probably slow down Team X, which will reflect badly on the manager of Team X if the company happens to operate internally on politics like most of them do — ie through the haphazard opportunistic misrepresentations of statistics to stupid and/or overworked people with the power of appointment.

So it’s far better if no one on Team X found out that they had something useful for Team Y in the first place. Then the manager of Team X doesn’t have a headache, doesn’t need to explain why he’s helping or not helping, and so forth. Everything runs according to plan. And the plan is not to be excited or invent anything new. If communication only happens through the hierarchy then we can make sure it all works without creative disruptions.

Actually, maybe sometimes a commercially damaging fact might leak through in such a back-channel between techies. At least that’s the fear.

For example, Company P is licensing some piece of crap software from Company Q for years and years and paying a lot of money for it when it could be rewritten or replaced in about an afternoon. Is it ethical for Company Q to keep this information secret? Apparently so. Although it’s not addressed in the two hour Code of Conduct interactive webinar I just had to sit through this morning, which was mostly concerned with the problems of insider share dealing, and makes questionable assertions, like ethical conduct means being legal, and unethical and illegal conduct is commercially damaging. Who makes this crap up? Do they think we don’t read newspapers?

Although they might not have thought about it, I don’t see why the programmers in Company Q should be uncomfortable by this information becoming generally known. I mean, it’s in their interests for the revenue of Company Q to depend on the software being good and actually valuable, because then they might get some quality work to do. Everyone is enriched. Company P saves money and is served with some better software. The programmers in Company Q finally get paid to do something productive. And the managers of Company Q are no longer forced to suck off on revenue that depends on all their customers being stupid idiots.

I don’t like putting out these theories without examples in mind. And I do have an example in this case.

It’s Perforce.

What a piece of unmitigated dog poo! Companies pay about £500 per programmer to access this out-of-date, obnoxious, clunky version control system that is no good at all. There are numerous free alternatives that are vastly superior. I shouldn’t even need to name them. Where does the money go? It certainly isn’t put towards making an even half-way usable interactive client. Why does anyone in the world buy it?

Anyway, it’s time to put dinner on. Back to some tech stuff later. I’m building a backlog and not getting out flying any time soon. So I’m grumpy, in case you haven’t noticed.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>