About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Too Much

Will it always be this way?

Get It

Try It

There's just too much evil in the world. Right now at least. Or perhaps it's always been this way. Will it always be this way? A world without end, without beginning, beyond time?

Or is it because we're more aware today, with the electron speed of global communications, and how we can collaborate collectively to see through the bullshit?

Whatever. It doesn't look good.

Once upon a time this was only about programming. About getting a program spec to write a program, in some language, like IBM COBOL or BEP or - preferably - C on Unix or MS-DOS or, later, Windows.

Sure, we saw stuff. We saw a lot of hypocrisy. A lot of bullshit. We saw a career category of professional bullshit artists. It was IBM who created that niche, we were told. The techies were too savvy. IBM salesmen could only sell so much junk before the techies caught on. Push the mainframe sale through the door, fine. After that a few peripherals. But gradually the techies understood that there wasn't enough bang for buck anymore, and so they started saying 'no'. That's when IBM invented the systems analyst. Or so we were told.

It was necessary, advised IBM, to have a special systems analyst type of employee in programming shops. But this systems analyst was to only specialise in understanding clients - not computer languages. The perfect analyst would not have a clue how to program. His job was to be the interface between the client and the programmer, said IBM. And it was a very important job, said IBM. So systems analysts were to be ranked higher than programmers, and paid more too.

And, when it came time to evaluating purchase proposals from the IBM salesmen, you turned to the systems analysts, not the programmers, not the techies. Which was perfect, for IBM. For those systems analysts didn't know shit.

'I've been a systems analyst for twenty-six years', said this bulky effeminate Yugoslavian to us one day. 'And I'm proud to say I've never written a computer program in my life - in fact I don't know the first thing about programming!'

That's what we were up against.

There was the structured programming frenzy. 'It's all bullshit', our eighteen-year-old blonde instructor told us. 'But just keep your head low and don't be too outspoken about it - management love shit like that.'

Thanks for the advice!

We started an underground newspaper at work that made fun of all that stuff. You had to do something - it was all so fucking ridiculous. And you learned that you thought one way but acted as if you thought another. That was the name of the game, the nature of the beast.

Few people are really good at programming, but a lot take the job because it pays well and because it's easy to bullshit your way through your career. We had one guy, actually an archeologist, who got a job as a programmer because everyone was desperate for programmers. He never did anything, but no one noticed. He'd always have his office door shut. He'd sit at his desk, across the room, by the window. He'd have a binder in his hands at the desk. The binder was work-related, but inside the binder he'd have the magazine he really wanted to read. Something about archeology, or sailing, or antiques. At his left foot he'd have the bottom desk drawer open. If someone knocked at his door, he'd let the magazine slip into the desk drawer, he'd push the drawer shut with his left foot, and then called out 'come in!' It worked like a charm.

Worst were those who caused harm. The archeologist caused little harm - his effect was lost in the general pandemonium in effect as it was in most software houses. But the ones who used their somewhat exalted positions to cheat - and cheat in a way that harmed others. Or corporations. Or the public at large.

Our company planned on uniting 953 offices in one of the world's first online Unix systems. The Unix was something called 'MERT' - 'Multiple Entry Real Time'. But how to get there? Yours truly was chosen as head of a four-man 'admin group' that would work side by side with the original programmers and then take over the code on delivery, and I was chosen because I was the only motherfucker who knew anything about C and Unix. But the system itself? Who was going to make the hardware, who was going to write the software?

Three companies bid for the contract. The first, a totally Swedish company, today a household name, had a sort of bid. Their terminal hardware was mostly manufactured in Sweden, but parts of it came from IBM in the US. As for the software: they had nothing, nothing to build on, but they were confident they could write it, even though no one in their organisation had the foggiest about Unix or C.

The second corporation was IBM. They already had systems like that. With a few minor modifications, they were basically ready to rock 'n' roll. Their bid was also the cheapest. The hardware was already there, and the software basics were also in place.

But they got passed over by management who took the third and final offer. That offer was by far the most expensive. Worse still, their products were already in use by us, and they were awful. Programmers talked of the 'spaghetti code'. The machines crashed all the time. The people who used those systems were elated when they heard there was a new system coming - 'at last we're getting rid of this junk!'

But this potential provider had nothing to build on. They couldn't decide what hardware to use. Worse still, they'd decided not to build this realtime system on realtime MERT Unix but on ordinary Unix - in tests in their own labs on the continent, they'd seen that data got lost on blackouts and brownouts.

And they had no C programmers. A trade mag carried an ad for C programmers who could travel to Copenhagen and help build a 'simulation' environment. The plan was to build a makeshift system with the Wizard of Oz behind the curtains to impress management from our company who'd be led to believe that what they saw was real - when it wasn't.

But they couldn't find the programmers anyway.

Top management used the services of a Swedish systems analyst employed by a big British consulting firm. This analyst, it turned out, was on the payroll of that third ominous contract bidder. It was his job to convince top management to take the by far worst bid - as that was from the company putting extra cash in his pocket.

How did he do that? By convincing his superiors at our own company that this offer would mean more money stayed in the country. When in fact the truth was the complete opposite.

Several months into the project, we were called out to a nondescript hotel south of town. This was a secret meeting, we were told. Our own CEO didn't even have this news yet. But our contractor had just admitted they were behind schedule by at least one and one half years.

What to do then? Revise the contract. There were no penalties levied but, in the future, if our end were to fall behind (we still had nothing to do yet) then our company would be fined. Not them. As we took off for a coffee break, this Swedish worm sat down at the grand piano in the room and started to rip off 'Happy Days Are Here Again'. I sat down next to him and asked him point-blank why we didn't just cancel the contract and go with IBM. 'Because the people we're working with now are the best for this project', he said, without so much as looking up.

Sweden's biggest bank decided to also get into the online system business and made a big deal in the media about 'buying Swedish'. They chose contractor two. Who totally fucked up. But only once. The bank's lawyers walked in like the mafia, walked out with coffers full of cash, signed with IBM - and only weeks later they had a test location in the old town running the new system. Weeks. Where the bank had been waiting months and we'd been waiting years.

Our Swedish analyst with the British consultancy also had four test operators at his disposal. These were ladies who'd worked on the shop floor. Not programmers. More the kind of cashiers. They were to devise test routines for when the system was ready.

But our Swedish analyst was afraid my group of four programmers would see through him. So he reversed our roles. We were to devise test routines and the four cashiers were to stand by and oversee the actual programming when it began. Except it never began.

Then there was Nils. Everybody loved Nils. I never met him. He'd taken sick leave before I arrived. Nils was the technical expert. He was the antipode to the Swedish analyst and his freaking female colleague who had a Tourette's thing going.

Online booking of theatre and concert tickets was a big things. Cashier machines were to be capable of displaying the seating arrangement of any venue in the country which would also display which seats were available (and which were already taken). The customer would then choose seats, the cashier would put in the order, and the system would verify in a second or two.

The cashier machine would run in its own office local network. A dedicated machine would pick up traffic on the line every now and then and send it, as needed, down the line, to central office. The packets would thereafter be routed to the right floor after leaving the primary mainframe.

The packets, marked as part of the online system, would then be routed back out of the building and onto the secondary mainframe, where it was decided the main part of this online system would reside.

But once inside the secondary mainframe, the packet would be discovered to be for online bookings. The computer system for online bookings was back in the building for the primary mainframe, on the floor above the primary mainframe.

So the packet would head back to the primary mainframe, there be seen as belonging to the online booking system on the floor above, and routed thereafter. The system on the floor above would determine if the desired seats were available and prepare its reply. And the reply would go back the same way it came.

Out from the booking system, down one floor to the primary mainframe, back to the secondary mainframe (30 kilometres away) as it was part of the online system, then routed back to the primary mainframe again as that was the hub for the whole system.

Then back on the line, back to the office it was originally sent from, then into that network, where the main office computer would put it back on the local network, where the cashier's machine would pick it up so the cashier could show the response to the customer.

Did the customer get the seats? Or not?

That entire process was to take two seconds. At the most. The User In Control Principle states that wait times should at most by 1.5 to 2 seconds. Otherwise display an hourglass or a spinning beach ball - preferably something that moves and entertains.

That's the system devised by the Swedish analyst and his Tourette's colleague. Neither of which had any formal training in computer hardware.

Nils had that training. His job was to oversee the weird ideas those other two came up with and say 'no' when things got too weird. He said 'no' here.

'There is no way that's going to work', Nils told them. 'Zig-zagging around the country, from one network to another, and back again in two seconds tops? No fucking way. Are you fucking crazy?'

Serious arguments ensued, over many days, according to those who were there. Nils knew his stuff. The 'analysts' were specifically trained so they knew nothing about hardware capabilities. This is what you get.

The Swedish analyst was nasty towards Nils. Nils just stood his ground.

Then poor Nils' poor beloved wife up and died out of nowhere. They had been so close, so deeply in love. Nils had a stroke as a result, got taken out on sick leave, and the Swedish analyst just carried on as before, except he had no realist interfering with his plans anymore. The design of the system was to remain.

The system was never completed. Several years later, the cashiers in the company were still waiting on delivery. That delivery never took place. The total cost to the state was in the range of hundreds of millions. The Swedish analyst who'd shilled in secret for the supplier, and who'd come up with design schemes as the above for online booking, disappeared into our own organisation with a salary comparable to our own departmental manager. That's how it's done. Who gets ripped off? Everybody involved - as well as the taxpayers. Hundreds of millions.

You've obviously heard of us, otherwise you wouldn't be here.
We're known for telling the truth even if it's not in our interest.
We're now telling you to beware Apple's walled garden. Don't get locked in.
What you've seen so far may be only the beginning of something far far worse.
Download our Test Drive and at least check out our free Keymaster Solo.
That's the first step to regaining your freedom. See here.

John Cattelin
Media Contact
ACP/Xfile licences
About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.