This probably belongs in a Reddit post somewhere, but... Anyone that's undertaken a software development career has probably encountered what I'm about to describe. And it's too long for Reddit, so...
I spent more than a decade of my three decade stint in software development working in manufacturing, and invariably, the companies avoided buying certain commercial off-the-shelf solutions and using them as delivered because "we're different than everyone else".
Sometimes, that claim is legitimate. Here's a candidate that supports that claim.
I joined a company that assembled large commercial ships, which required large steel plates for hulls, bulkheads, keels and the like. They had relatively limited space - imagine around 120 stacks of plates arrayed in a grid over 4-to-6 acres of floor space, with a big A-frame crane straddling it. There was a bunch of other piles of bar stock and forged I-beams beyond this grid, as well.
The plate department's challenge was to have the plates in position to move into production every day throughout the year, even though they didn't have enough room to accommodate the year's material in 120 stacks. So, over the decades, they devised a process that would allow incoming steel to arrive (for example) at the upper left-hand corner of the grid, and leave at the lower right-hand corner. In between the time a plate arrived and the time it was required for production might be 6 to 9 months or more, so the workflow needed to accommodate that time span. During that period, each plate movement was intended to help make the stacks nearer the exit corner progressively more organized, so that when the required start date arrived, the steel was all in one stack as close to the exit corner as possible.
The enterprise inventory management system could keep track of which department had stewardship of the plates, and probably was suitable for tracking smaller components by warehouse area, row, rack and bin, but had no capability for helping the steel plate team decide where on the grid to move a giant plate to keep material converging towards a single stack for the planned production start date.
Enter Microsoft Access ... circa 2000 was my guess. One analyst - not a formally trained developer - created a little Access app that could keep track of the plates and print out move instructions to show the crane and forklift operators where to reposition plates each day. The intention was to help them take the chaos of the entry corner and transform it into a carefully organized sequence of stacks by the time start day arrived.
The innovative scheme they devised was to name rows of stacks, and individual stacks within each row, in accordance with the stack's purpose, but not a specific start date. It was logical to name the rows and stacks at the top of the grid nearest the entry corner more vaguely. Think "Quarter 1, "Quarter 2" and so on. Towards the middle, this scheme became more specific, such as "Two months out", "One month out" and "This month". Finally they reserved a couple of rows nearest the exit corner to dedicate for exact dates, so that 14 days before a production start date arrived, they'd have an empty stack that they could start piling plates on. Thus the material for that day was all in one place.
This all sounds simple enough - any competent software developer could write a few procedures to help them perform a "converge" operation on a stack that they wanted to clear out for re-purposing.
Here's the rub: The plate department couldn't tell you all of the rules for plates that fell outside the simplistic process I outlined above. For instance, they might have special rules for departments X, Y or Z, and the rules might be different for each, but everything else would follow the general outline. Then there were rules for plates that were below a certain size or thickness, or above a certain size or thickness. You get the idea.
What's a developer to do?
AHA! Look at the existing code! Great idea, but, as I said, the innovative fella that created this app was not a developer by trade, so the code was crap.
Wait! There's more! He had left the company 5 years before I arrived, so as that app started to behave in unexpected ways, the department considered it "broke" instead of acknowledging that something about their process had changed.
My IT predecessors tried to maintain the app ... but our manager saw that it should be replaced, so he received approval to find a commercial replacement.
Two more years went by. The plate department could tell you about 60% of what the app did for them, but the "converge" operation was a mystery. And they didn't know exactly what all the tables in that application were used for. My predecessors then left, as well.
Enter your humble correspondent. Our department had spent about 2/3 of the replacement budget looking for a COTS solution. I walk in the door, 1000 hours already gone, and get handed this beauty on the 5th day I worked there. Oh, and can you complete this by Christmas? (We're in October when I find this out). Oh, and your prior responsibilities are a bunch of old desktop apps that need to be replaced. So I had about 20 hours a week to work on this.
Fast forward six months, most of the replacement is built, but the Converge operation is still a mystery to the clients, remember that it's THEIR process, so it's still a work in progress. And we still don't know what all of the tables in the app are for, so we start whacking them until something breaks.
Our department (IT) digs its heels in one day and drags the main analyst and his manager over for a User Acceptance review, and we are told that they want to be able to relabel all of the stacks whenever the need strikes. You can imagine that this was never in the requirements - and you'd be right. The main analyst had told us that they'd never changed the grid layout before - but the new manager wanted this feature. And the label text of the stacks was required by the Converge operation in order to execute the converge logic for repositioning the plates in the stack being converged out of. We put this request on the software development backlog, but I made a deal with the supervisor: You define the details of the Converge operation - put them into your plate management system docs, if you want - and I'll give you an estimate of what it would take to enhance the application to do this.
Three years go by ... no Converge documentation, ergo no grid re-labling enhancement. Problem solved.
There's kind of a happy ending to this, in that I, with the occasional help of a contractor or two, delivered this app about a year late. And an even happier part was that we never got a service ticket on it that wasn't related to the data coming from the external IMS system. Several years, and no legitimate application errors.
There's also an interesting challenge for me, if I ever get bored in my old age. That late requirement to re-label the stacks (and presumably rows) could actually be implemented while retaining the proper functioning of the Converge operation. It would take several hundred hours, and might even require a home-grown business rules language, but I can picture it.
But I'm looking forward to the release of Diablo 4, so I probably won't have time. Too bad!
