I Want My PDP!
Long, long time ago, in the '80s, there were those things called Computers (with a capital 'c') that were f#ing expensive, used a whole room and a lot of electricity and could do one thing at a time. Usually they were doing some sort of very long calculation and when done, they were putting out ONE result, that was printed down on paper and given to the user that had asked for it and then the 'technician' proceeded to load the next job.
This 'loading' usually required dismounting and mounting disk, that you did using a spanner or two and some elbow grease, punching cards, rewinding tapes and so on. And then, the whole thing was started up hoping that nothing was going to crash it in the middle
The Computer couldn't do more than one thing at a time because... it had no Operative System. The way they were built, that is the same way is still in use in some tools, like washing machines, was with a clock, a simple clock that gives or take away power to some circuit at a time. Simple, direct and it never miss. When it does miss, is because is broken and need to be replaced.
But then... The Revolution! The computers (lowercase c) got Operative Systems, and that meant that instead of a physical clock, they had a virtual one. That virtual clock worked exactly like the old one, except that it was invisible and when it went bad, nobody really knew how to fix it. But on the other hand, they could do multiple things "at the same time", that in fact was a lie. What they did (and still do) is to do something for a very short amount of time and then move to something else, and then something else... and then they were going back to the first one and going on from where they stopped and so on. If you do it fast enough, it looks like everything is done at the same time.
The change was drastic... up to a point. Because all the peoples that used computers, where still thinking about "the old way" and they were still waiting to get their print-out with the data on, that kept being produced instead of explaining to the users that they could read the data directly from their terminals. And this went on for a long time.
And today, that it's almost 2020 and almost 40 years have gone by, I talk with peoples that still thinks about Computer with a capital 'c'.
Let's take $brinkandbrank for example, an unknown company that does... things and they sell them too. These peoples used an external company to manage their distribution and wearehouse, basically they were managing production, sales and marketing while the wearehouse and distribution was done by a different company. And of course all the business was managed by a series of applications.
And I had the privilege of figuring that out on a nice (kinda) January morning, when one of $brink's CL phoned us.
CL1 - I'm CL1 of $brinkandbrank, we miss the TR_RET_LAM_20090112_315989_TGAX_DOP.TXT!
Me - ...what are you missing?
CL1 - The TR_RET_LAM_20090112_315989_TGAX_DOP.TXT!
Me - ...have you checked under the couch? Normally when I miss something is in there...
CL1 - Don't try to be funny, this is important! Without the TR_RET_LAM we can't process the TL_RET_LAM and the whole procedure stops.
Me - (looking into the documentation and finding nothing) Hemmm... Ok, I've no idea what you're talking about. Can you explain what is this RECTALTROM?
CL1 - TR_RET_LAM! Is a very important file that we need to process the TL_RET_LAM!
Me - And where should it be?
CL1 - On the system of course.
Me - Which system?
Let's skip the discussion that went on way too long, because CL1 assumed that I knew everything, not just the logical structure of his organization (that wasn't documented and was also severely lacking in "logic") but also all the details about what that "process" should have been.
Anyhow, after a lot of time and some check, I reached the conclusion that that stupid file was generated somehow by some application belonging to that external society and then placed on an FTP server from which $brink was supposed to get it using a cronjob. With an entire collection of other files with similar weird names.
And the procedure required that those files got then somehow "merged" using Excel and the resulting datamonster digested by their ERP application using another cronjob, the end result then... I don't know, but suspect the result would have been exported into yet another TXT file and the uploaded on the same FTP.
After following several turn and bend, I got the ftp login credentials (admin admin, what did you expected?) and check. The file ain't there.
CL1 - What do you mean the file ain't there? We need that file! How do we process the TL_RET_LAM without ?
Me - I don't know how, but the problem is that your external company didn't made one, so ask them why.
CL1 - But... The TR_RET should be ready before 8AM every morning! Why isn't ready?
Me - I told you: ask them not me.
After repeating the previous thing several time, CL1 decided that was time to call their delivery company. And then I heard nothing anymore until we were asked to add a monitor check to control that the file were present at 8 AM. And obviously if they weren't, WE were supposed to ask their delivery company, that obviously didn't had a 24x7 support and weren't very happy to answer the phone either. So the escalation procedure was: turn the alert off and wait the next day.
After several "problems" caused by that procedure, somebody had the brilliant idea to ask US how to make the thing more efficient.
CL2 - So if the FTP was faster maybe we'd had less trouble...
Me - And if we try to bring the whole procedure in the 21st century?
CL2 - ...what do you mean?
Me - Well, this bunch of files that you have to copy and then rummaged around are generated by some application that read the original data from one or more database, unless they make up stuff on the fly, instead of producing a bunch of files, why don't you let that call an API in your system and deliver the processed data directly in your system instead>
CL2 - API? What's that?
...and at this point I started to explain to this guy, that wasn't that old, that there is this magical thing called THE INTERNET that allow computers to talk to each other at the speed of light, and you can tell a computer that when an order is ready, instead of waiting the next day and create a file, it can simply call the other machine and tell him directly, and that other machine could... I don't know... do something with it. Without the need to copy files up and down and into excel and so on.
CL2 - No, yes, and who is going to do that?
Me - What?
CL2 - Our ERP software doesn't have the wasps there...
Me - Your program is developed by somebody that probably can implement the changes without too much problems, and the same goes for the software that is used by your other company, if it's something built in the last 10 years I wonder if it doesn't already have those. We're not talking about sci-fi after all but stuff that exists since the 2000.
CL2 - But is too expensive...
Me - If those files are so freacking important that we're sitting here talking about it, then it should be worth to see if the whole thing could be addressed, not just patch it.
CL2 - But if we put a faster FTP...
Yes, because everybody want a mainframe...
Davide
20/12/2018 11:20
Seguo le tue storie via RSS (https://www.soft-land.org/rss/softland/sdsm.rss) con Feedly. Purtroppo, questa (https://www.soft-land.org/storie/19/2) non compare nei feed: si passa da "Testing, RoboTesting o NoTesting" a "il buco". E' un problema di Feedly o il generatore di RSS non è a punto? Tremo al pensiero di essermi perso altre storie. Grazie!
