- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Incredibly sad how few companies seem to have any sort of clue about anything yet still manage to chug along ignorantly.
Admin
It's sad, really, how we don't learn the lessons that the past thrusts upon us.
People knew FIFTY GDMF years ago that you can't computerise a human business process. What you do is you change the business process so that it's compatible with being computerised, and you computerise that.
And you offer Old Fred a generous early retirement package(1) so that "Old Fred's Report" is no longer an issue. That's the one that Old Fred spends 19 working days of each month to produce. It is a work of art in the field of futile time-wasting, but it means that nobody has to tell Old Fred (who's been at the company for longer than it has been a company) that there really is no more work for him to do (he's probably well aware of that, in fact). Nobody, not even its most fervent advocates, actually reads the report, but it's useful as a stick to beat the computerisation project with.
(1) It's less illegal than finding a nice man who'll put Old Fred and his GDMF report out of your misery.
Admin
I'm grateful not to work for such an org. The horrors. This is one of those stories that's truly Worse Than Failure.
Admin
Did anyone in management really think this was going to work? 3 weeks to replace and ERP? replaceing an ERP without massive amounts of process docs and stakeholder demos along the way?
Honestly this reeks of two or more middle middle managers disagreed about a make v buy decision and the losers have managed to sabotage the project in its cradle. So they can say hey look guys "We could not even manage the requirements gathering internally, this time we go with Enterprise Product and HPCs to deploy like we wanted!"
Admin
"Did anyone in management really think this was going to work?" Yes, they did. They always will. But one can split management into three groups: the managers with no software experience who think that everything is easy; the managers with software experience who understand the difficulties and set reasonable goals and deadlines; and the managers with software experience that they have completely forgotten and now think that everything is easy.
Admin
I'll give you #1 and #3 but the rest is sheer fantasy. I mean, seriously, a reasonable manager? Do you believe in the tooth fairy as well?
Admin
Did any of the developers in the "big meeting" push back on the unrealistic deadline? The narrative suggests maybe, but there is a time when we as devs have to dig our feet in and hold our ground, otherwise when the deadline passes without the work completed it's now our fault.
Does a patient go into the OR and tell the surgeon "you have one hour to get this done"? Yet in software we seem accept this kind of thing all the time.
Admin
They should have applied the best-of-the-besttried-and-true Enterprisey solution: Do nothing because it works and change it when the next ERP is implemented in 2037.
There are a few ERPs out there that actually work this way, hoping to use this "real-time" clusterf*ck of a "messaging" system as a selling point. Muppet News Flash -- almost all ERP systems today are real-time in the sense that as soon as a transaction is released to the system it will show up wherever it's appropriate.
TRWTF here is that they're using a 25-year-old program with 60-year-old logic. And it's not alone. At the time that Java program was written in 1996, I was working in an office where the accounting system screens were actually set up like 80-column cards. You want to enter an invoice for payment? Easy! Pull up screen 54 and fill it out with an IA at the top (vendor, invoice #, date) Then comes an IB (PO#, voucher number, total amount), an IC (invoice comment - 70 characters max), one or more ID (distribution), and an IX (no joke, "this invoice is ready to transmit"). The entire system -- in 1996 -- was built in a way that data entry was nothing more than a visual screen representation of punch cards!
Admin
Makes me feel better about the terrible org I worked for up til last year. At least there changes happened on a daily basis; the only changes that occurred when the project was over was it being canceled entirely.
Admin
They broke all my rules - they bought third party software, they used a third party ERP, and they hired consultants. This is Chernobyl level of incompetence. They made it impossible for the reactor not to blow up.
Admin
What is this, some European joke I'm too American to understand?
Here in the US, we'd just fire Old Fred and tell him to suck it.
Admin
Reading is just as important as writing in the coding world. Diagramming an undocumented (or crappily auto-documented) system and reading a giant mess of code are mostly inescapable skills.
Admin
Same vintage, same tee-shirt.
We y2kd a customer's system.
We used a Java app to read data from an Oracle database, squirted it via a socket written in C to a VAX on which a Fortran program carefully formatted the numbers into reports in the form of a COBOL data file (complete with EBCDIC coding) which we then FTPed to a 3rd party whose job was to print them all out on teletype printers fed with concertina paper, which would then be snail-mailed to the customers who would then be invited to scan them into their system to be stored as PDFs accessed by, er, ahem, an Oracle database.
That's what Customer wanted, that's what Customer got. And because it worked so well, we kept this going for another decade or more. I moved on to pastures new so I don't know what happened to that customer in the end.
Admin
The problem is that you can't fire Old Fred because Old Fred is Old Friends with far too many senior management to get fired. If you try to fire Old Fred, one of his Old Friends will catch wind of it, and suddenly you're on his shit list -- and Old Fred is not fired.
So you have to sweeten the deal enough that the Old Friends will think this is a good deal for Old Fred, and Old Fred will think so, too. And you need Old Fred to be at least a little on board, because he knows where the bodies are buried.
Admin
RIght. Been there, done that. "Optimistic" deadlines, secret specifications, dozens of terabytes of data, "immortal invisible architects wise with specs inaccessible hid from our eyes," the whole dealio. Add to that a bunch of margiinally competent and stunningly lazy database adminstrators. It's a miracle the big data-ingestion project I tried to lead worked at all.
Admin
That there is an impressive chain of enterprisey data transfers. Pat yourself on the back for getting it to work end-to-end, and without benefit of a wooden table ...
My nearest equivalent to that was a straight-forward ASCII transfer of mangled credit card reconciliation data from a Multicsy C system to a Cobol mainframe. (So simple, it never failed.)
Come the hour, come the Huge Consultant Bean-Counter, "advised" by a Huge Consultant Architect that we needed to replace one Multics with another Multics. (Plus C++, but that's just icing.) Turned out to be dog-slow.
My manager (who later went on to greater things as a white goods sales manager) decided that the problem was the transfer format. "Too much white-space!" he declared. So he invented a whole new transfer format that "compressed" a TC45 into a TC45-no-whitespace before sending it, and relied on the Cobol back end to "uncompress" a TC45-no-whitespace into the original TC45, which is what the mainframe was designed to work with.
Weirdly, this seemed to slow things down by about 10%. And the reason couldn't possibly be because we already had actual compression in place across the interface, which meant that the supposed "overhead" of white space was practically zero. And, er, the actual compression was left in place (because it was low level comms), so in the unlikely event my manager made a difference, it was never going to be much.
We accused him in a company meeting of lying through his teeth. (At this point we were near walking off the job, anyway.) His response?
"I've got the data to prove it, but I left my calculation sheets at home."
Seriously. By the time you're 30 or so, you realise that bullshit beats competence and honesty, every single time.
Admin
By the way, I've never quite worked out how this "manager evaluation" thing works. There's some point where they get shoved out the door, but I'm not clear on what the exact metrics are.
"Dave," for example, and I'm going to call him by his real name to protect the innocent, was entirely bereft of knowledge, either in the software field or the business field, when he was hired. He was also a clinical psychopath. (Not me that noticed it. Several co-workers pointed it out.) His dual obvious "management" skill was sucking up and crapping down, which is usually good for a life-time of slithering up the greasy pole.
But at some point, and I really don't know when, he got bottom-ranked in the notional stack-ranking management evaluation system. And to be fair to "Dave," and ignoring his thousand-mile stare through eyes that were at an obtuse angle, I would have ranked him at "mediocre" rather than "bottom feeder." It was a credit card company. Credit card companies have more bottom-feeders than an ocean full of nutritious algae can support.
It's a generally unanswered question on this site. We all know when we think a manager should be fired/shot/retired/reassigned.
But at what point does upper management make that decision?
Admin
Your reference to bullshit beating competence explains the acronyms from the article: AB = average bullshit; ABC = average bullshit confirmed; PB = pointy-haired bullshit; PBC = pointy-haired bullshit confirmed; GC = garbage confirmed; and of course: "Rejected" = (bool)FILE_NOT_FOUND.
Admin
When a bank want a new system, they go for the latest of the latest. Then they want to stick to it forever. Many trading applications relies of interfaces from the 70ties. Airfreight relies on telex messages Airports in middle of nowhere might still have a telex machine.
Admin
"3 weeks to replace and ERP?"
No, they just wanted to replace a single data flow. An undocumented, not-understood, extremely complex and complicated data flow, as it turned out.
Admin
Which, er, just happened to deal with a significant chunk of business-critical behaviour:
"The first segment to be upgraded dealt with contracts."
What sort of insane person would start at that end of the business domain?
Admin
Surprisingly, probably not.
I was an APE at the aforesaid credit card processor, which is to say that I dealt with practically all their "small client" asynchronous programming engineering. This was back just before 2000.
I had lots of fun with (non dick-pic) polaroids of cable setups in the jungle somewhere. And I quite enjoyed dealing with the four remaining telex machines spread across the world, largely because I could claim, and convincingly claim, that I was the only person in the entire international organisation who could remember the telex protocol.
As far as I know, that credit card company took the easy way out and paid whatever it took to update their four remaining customers to something far better. Which might have been an unencrypted AOL chatline, for all I know. But not "telex."
Wonders never cease, but I think telex might have predeceased.
Admin
Am I wrong to be feeling a sense of nostalgia?
Software archaeologist is quite a lucrative and entertaining career path, I can confirm ..
Admin
I'm thinking of applying that lucrative concept the other way around, by writing a book that explains category theory to Cobol programmers.
Wish me luck.