JCL was the first “language” I Iearned as data control clerk. It was common to call it JCHell since you had to be so exquisitely precise, but eventually learned to love it because of that. It really is perfect for what it’s designed to do.
Things do get complicated when you need systems to talk to one another. I did a fairly complex ‘middleware’ project like that where we had to use some undocumented CICS, ahem ‘features’ to accomplish the interface with a local area network that was the inteface for a few dozen lab robots. It wasn’t elegant, but it worked.
I should have been clearer about my objection. bash is also powerful and likeable, and the JCL-like scripts in question would eventually be translated into the equivalent of bash-like scripts anyway. It was the introduction of this unnecessary extra level of obfuscation I found silly.
That how I became an Easytrieve god to some of my users. They were used to asking for reports with certain features, well begging really, and then having to wait for ever. When my manager took over the dept, he showed me how to do some stuff in Easytrieve so I could take over for him and I thought it was such a cool software package I learned as much about it as I could. Pretty soon I was turning reports around for them multiple times in a single day.
Just realized I’ve been getting dropzone and drachillix mixed up. I was wondering why the computer repair business was going to poorly that you had to help out telemarketers.
As for the thread: And I thought the local web design people were messed up (designing navbars in Flash, for example). This is a whole 'nother level. I’d always thought these stories were just one-offs.
BTW, I think a major cause of trouble with the system for Bored Motor Company I mentioned was unclear or changing user requirements. For example, I was told that the shift schedule could be changed after the shift had already occurred. This prevented shortcuts in the shift summary software. Negotiations with user had taken place before my arrival and at a higher, Peter-Principled level, but I wonder if the occasional statistic affected by shift-rescheduling could have been handled simply with manual notes.
Or maybe they were worried about Swing Shift Foreman saying “Hey, due to accounting delay the next hour will be credited to Day Shift Overtime. Everybody fuck up all you can and make Day Shift look bad!”
… Still, $1 million price quote to port a click-counting system from one Unix-based C compiler to another. :smack: :dubious: :smack: My mind still boggles. That was 28 years ago or so when $1 million was real money.
I actually bust out my scope-creep-dance™ (picture a zombie with a hand-held telescope and you’ve got the gist) at the office. My staff gets a kick out of it, which is nice, since they certainly don’t enjoy the actual scope creep.
Back when I had job skills I worked for a company that made custom control panels. My job was the faceplates, laid out to be punched on a computerized punch press. It was an obvious waste to be drawing new faceplates all the time when they were all basically similar, so I put together a proof of concept, parametric design system using the extremely basic BASIC the CAD software used for customization. (Those of you from Altair or TRS-80 days would recognize it as pretty much Level 1 Microsoft BASIC without the frills. I was doing parametric modeling with a language that fit into 4k. Suck it, SolidWorks!) Later I did another proof of concept of that Excel-ized the quote form, outputting both a quote and a parts list with the parts in the order in which they were found in the parts cage, to eliminate wasted steps. I proved these concepts well enough that management brought in outside people and gave them a million and a half bucks and several years to do the full-scale version. I’d’ve happily done it for a quarter mill in a fraction of the time. Hell, I’d’ve done it for my regular pay if I got some recognition for it.
When asking someone to build a piece of software, you should tell them what you want the software to do.
You might think this was obvious. Apparently not. I’ve lost count of how often I’ve been told to build a piece of software with essentially no specification. This isn’t even blue crayon floor plans. If I were a carpenter, this is the equivalent of waving vaguely at an empty lot and shouting, “Stick a house on this fucker!”. Requests for clarification would either result in “Don’t you know what a house is?” or “…and I want six frozen pizzas in the fridge!”
I currently work (what I think of) as a middleman programmer - I take data from sources managed by other departments via applications created by other people then build interfaces that users can understand to pool data from multiple systems into something as simple as possible.
I see it both ways and I can tell you its just as bad on both sides of the fence.
On the one side, i’m currently using (as an example) a datasource application that’s been running as ‘live’ for over a year, yet has not been signed off with even basic functionality yet. It falls over on a weekly basis and the data is dubious at best - and a year its just the live time, it was in the installation phase for the two before that. I wont even get started on how bad their support is. Its a major company and we have to not only bug find, but prove every time the existence and severity of the problems, since their first reaction is always to disbelieve us.
On the other, I recently completed a project for one of our teams. It took two months, one of which was solid scoping- time spent with the team lead/his boss/his employees working out what was actually required, instead of what was asked for. (A crayon drawing would have been an improvement on the original request).
Eventually agreement was reached. Every t crossed, every i dotted. Development went ahead (with the usual changes requested and implemented mid flow)
It was released and for the first week everyone loved it, then the lead and his boss moved departments (which they had neglected to tell us was happening).
New lead/boss came in and wanted so many changes it would have been unrecognizable - quicker to start again. Functionally it was still fine though.
We had more urgent projects waiting in a queue we’d allocated time for - they had a system that worked. Our boss said no to them. Result was that application didn’t get used. Two months work wasted.
The point of this story? People everywhere are idiots, its not limited to one subset or another.
Oh, absolutely. But I think it’s fair to say that certain subsets of people have distinctive ways of being idiots, and this thread is specifically targeted at the stereotypical idiocy of people who want software built, but don’t actually understand anything about how to do that effectively, and the complimentary stereotypical idiocy of people who build terrible software. That’s why software horror stories are about evenly split between stories of incredibly stupid software management and examples of incredibly stupid code.
