Reply to post: Re: Isn't THIS why we've got to teach 2nd-graders how to "code", rather than how to think?

You're not Boeing to believe this: Yet another show-stopping software bug found in ill-fated 737 Max airplanes

Vometia Munro Silver badge

Re: Isn't THIS why we've got to teach 2nd-graders how to "code", rather than how to think?

I think a lot of the problem lies not with the programmer (though I'm not denying there's a lot of chancers out there... some knowingly, some not) but with the environment. I mean that particular landscape that features a lot of silhouetted pointy hair.

Casting my mind back to the early '90s, there was a serious problem where training courses were used by managers who wanted to keep their headcount up without having the amount of work to justify it so it gave idle hands something to do. Of course if they were better at managing then they might realise that maybe if they shared the training with the staff who were actually on chargeable account codes they may end up with more staff on chargeable account codes and fewer staff at the extremes of being either burnt out or bored shitless. But that's not how they think.

The culmination of this was the horror called Rapid Application Development, which meant dragging some unwary, unwitting and unwilling programmer into an ill-defined project involving systems they'd absolutely no experience of, knew nothing about, often never heard of and certainly weren't going to receive any training for. The specification would be verbal, imprecise and would change every time it was discussed typically in that ubiquitous meeting place better known as the corridor, and requests for clarification typically resulted in being signposted to somebody else who predictably knew nothing about it and/or was so pissed off with the whole thing that they didn't want to discuss it either way.

Oh, and of course there was absolutely no sort of planning, design nor version control of any sort. Better project managers liked version control for the usual reasons but it seemed to be viewed as an obstacle to the rapidity of RAD.

Even as a fairly green programmer who ended up having to learn a lot of stuff the hard way I realised this absolutely stank to high heaven. To this day I feel pretty awkward about anybody encountering any of the stuff I wrote back then, whether or not it has my name on it. Though to be honest, prior to RAD there were my own inept attempts to find my feet in a team of pretty much one, so they were... well, hopefully not as bad, but still quite random. I'm also reminded of the poor chap who worked on one such project before I did: how I swore about him at the beginning of my tenure, but after not very much time spent working in that environment I quickly realised he'd made the best of a bad job and subsequently and sensibly made his excuses and left.

The ethos was pretty much "make it work any way you can. I don't care how, just do it quickly", the obvious undertone being "make it look like it works, I'm expecting a botch job that's good enough to get a sale". Not nice. I wonder if whoever was intended to be in receipt of this wondrousness knew what was the deal; or likewise if they even cared. Which seemed to be the problem: a lot of bonuses and promotions for both producer and customer were riding on being seen to have something delivered and nobody really gave a toss about whether it worked or would even be used. Nobody who was making decisions, that is: the people at the ugly end tended to grumble until sooner or later it was time to call it quits.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon