We've just had a new computer system go in at work. Lets say that it works, sort of, but it leaves a lot to be desired and there is a lot of tweaking that isn't tweaking. Stuff that should have been caught during testing.
It reminds me of back when I wrote applications for Blue-Chip companies. I wrote the first HSBC telephone banking application, the first B.T. 150/151 call steering application, and managed installations and upgrades for the likes of Goldman-Sachs and Commerzbank.
Had 9/11 not happened I might be still doing the same sort of job. Actually I might have been retired by now. But 9/11 sort of changed my aspect on family and rather than fly all over the world and rake in the money, instead I concentrated on the family and my disabled son. The IR35 tax rules sort of provided a perfect storm of circumstances that persuaded me it wasn't worth the hassle.
It's interesting and a little frustrating to watch other people's programming standards. I get that this application is a little website and associated back end system, no -one is going to die or lose millions if it doesn't work correctly, but it just annoys me a bit that other people aren't as fastidious about their adherence to good practice.
For instance there's supposed to be a functional spec, but none of us users have seen it, so we've not had any input on the way the application works for example. That's been done and signed off by someone that has never visited us and seen how we work. Instead we've been presented with an application that accepts orders from a website and that's about it. All the "Fun" stuff like cancelling orders for customers before shipping, or amending the order before shipping? Nah, not there. Oh, you want to create orders for foreign customers and send them details in advance so they can pay by PayPal outside the system? Oh, we didn't know you did that.
Using an off-the-shelf open-source system to create the website and all the back end functionality isn't the best option and I get it, there are limitations. But if you can't program round the limitations of the platform, then really it isn't up to the job. But then that's the job of the Project manager to assess the suitability of the chosen platform and if necessary change it. It's a bit strange selecting a platform and then bludgeoning it to suit your requirements. That reminds me of the HSBC job, where the original contractor writing the program coded himself into a corner and swanned off to the other side of the World at short notice. I stepped in and sorted that one out with a bit of lateral thinking. That earned me 70K.
I was just struck this morning that as an independent IT contractor back ooh, 23 years ago, that I must have been working at a heck of a level and never realised it. For instance working for a bank: when you have £4m public liability insurance, that would cover maybe a slow couple of hours of downtime if something you did caused the bank's systems to go down. That sort of focusses you on being definitely on the money and delivering a system that works.
I wrote applications for British Telecom, I managed the first successful upgrade of the Goldman-Sachs call-recording system that Thales had installed. That was a £14m project.
I just didn't realise at the time how big a deal it was.
My colleagues are currently highly focussed on IT issues by this install and are also now watching the new TV series about the False Accusations of Fraud created by the Horizon System used by the Post Office. I used to work for ICL that eventually became Fujitsu, so I was aware of the Post Office debacle as it happened in real time and I could never understand how the victims could never get a forensic analysis of the Horizon code done in order to identify any issues in the code.
It's arrogant to assume a system is foolproof and error free. There are many examples of unintended consequences where you write a bit of code and it inadvertently affects the code somewhere else in the system. I always tried to boil my applications down to a known set of subroutines that do specific tasks. The processes are built up by calling each subroutine in turn so that if there is an error in a subroutine, it happens everywhere that subroutine is called and it's easily and quickly identified and dealt with.
But I have seen some sloppy code where every process is a new routine, so it's entirely possible that in some rare instance a routine is called that is incorrect, but it's called so rarely, under special circumstances that it's virtually impossible to identify the issue and rectify it. That is, unless you have a VERY accurate test regime that tests for EVERY option and has the correct result already in the test results, so the error can be spotted.
But those were the days, co-ordinating huge call centres to stress-test my applications, Fully documented test regimes and pretty flawless applications. My last one at Carlsson Marketing ran so well we kept getting calls and visits from senior staff asking if it was actually live, because they'd had no complaints, no errors, no issues. The app kept on doing what it was supposed to be doing even if customers tried to break it.
And that's what I liked the most: coding for exceptions and issues and making sure they were handled in a correct manner, making the computer handle the issue politely, if you like. After all a phone line can go down, the link to a server can fail, anything could happen. It's up to the programmer to code for the unexpected and handle it in a manner that doesn't crash the system and informs the human using the system exactly what has happened and why.
Posts
