Extremely Important
This is another "non-tale", in the sense that there isn't an "end" to it and, unfortunately, nobody gets hit with a nicely planted baseball bat on the head as reward for the asinine behavour. But since it seems a very well-established behavour, I have to write about it.
As I said multiple times, my opinion is that if there is a "thing" that is pivotal in the chain that, in the end, deliver money into your pockets or bank account, you should take care that the "thing" gets all the required maintenance and support. Before and during purchase or acquiring, during implementation and, moreover, during maintenance.
No matter what this "thing" is. Being it a tool, a technology or people. If it brings you money, you should take care of it.
It shouldn't take a genious to understand what happens when this simple rule isn't followed.
At least, it shouldn't if you have at least 1 gram of functioning brain. But it looks like this very important ingredient is almost always missing in the heads of whoever is in charge, even if they are the ones that should be more interested in the matter.
To portrait the thing, I'll take as example not just one company, but a whole collection of them, because all of them can be coalesced into a single item that represent all of them. As such, I'll call this "company that is not one" $integral.
They had a ... thing, that provided different services for several customers and everything was based on a collection of more-or-less standard software glued together with a plethora of ad-hoc scripts.
What's wrong in all of this? Nothing... As long as you keep the thing under control and can do maintenance and changes when required. But if your idea of "maximize the ROI" is "let the first asshole that walk in the door do the software and then kick him out when it (barely) works", you have a problem. Between your ears.
Now, since I've already glued lot of idio...hemm.. customers, let's add some detail.
As said, the base of everything where a number of software that implemented well-documented protocols, some of them as old as Internet. The problem was in the plethora of scripts used to either glue different pieces together or "extend" the functionalities. Those scripts were made either in perl or python, and were written by different people in different time and with different style.
Since some operations were quite complex, somebody (I suspect somebody else from the script developers) decided to add a database to the system, a nice (let's pretend) MySQL. Unfortunately, one of the "developer" was quite a creative lad, that decided to add a series of Stored Procedure to the picture.
And what is the problem? You ask. It depends how you use them, say me. Because to have a script called in Cron that execute a stored procedure is no problem, but when the stored procedure create a temporary table, then fill it up with data coming from various tables, then write the resulting table on disk as a CSV file, then run a second script that read the CSV and use it as input to build another script that perform INSERT into the database...
I begin to think that whoever wrote this garbage was affected by schizofrenia.
Now, a procedure can be complex or complicated. And if you are asking yourself what is the difference between the two, is easy to explain. A thing is COMPLEX if it is composed by many simple things that works all together. Take a pocket watch for example. Is made up with lots and lots of small gears, each one of them is very simple, they all rotate or oscillate and drag the others in the motion, and, with patiente and care, you can follow the process and understand how the whole thing works. On the other hand, a thing is COMPLICATED when is made up with lots of complex things and how they are connected together is undefined or hidden (by chance or design). At this point it doesn't matter how patient and careful you are, you won't be able to figure out completely the function of that thing. Especially when some detail is missing from the picture.
So everything in that thing worked kinda ok (if we ignore some little problem) until, one day, one of $integral's customer decide to become an ex-customer. And at that point $integral had to modify its procedure to cut them out.
And them, of course, turned the thing to us. And we, of course, pointed out that "this stuff should be done by your developers, not us".
And almost immediately a giant fight developed because the various UL/SL of $integral said that since we were responsible for the server, we had also to be responsible for the application, and so also to provide fixes and changes to the same when required.
And of course I pointed out that 1. No, 2. No. And 3. Since we had no documentation whatsoever of the thing, there was no way to do any kind of change without potentially fucking everythign up and so No.
And of course, none of the various UL/SL involved was happy about that answer, so the thing was reported and repeated numerous time at several levels, and we also repeated that if $integral considered that thing "essential" for "business continuity", they should also have considered maintenance and support of the thing and not requesting changes ad penisus to somebody that didn't know anything about the thing and couldn't guarantee the functionality of the same.
What they had to do, was to ask some competent developer and produce a software with documentation and support.
The thing went on for a while, even with some request of manual changes into the database to 'fix' some little problem with the invoicing (since nobody knew how to change stuff in it). In fact, they were still talking about it when I left.
And why do I pull this shit out now? Well... there is this guy that has this bunch of VBS scripts that...
Davide
06/01/2020 13:28
