Software engineer fired, shut out of office for three weeks by machine It was only a matter of time before the machines started fighting back. And let's be honest, we all knew the software engineers would be the first to fall. And so it was that Ibrahim Diallo, in California, USA, found himself fired from his job, had his network access and his entry card killed, and was unable to get himself …
Read this on the bbc and their version of the article has him quiting and moving onto a new job. I don't understand the non payment of wages. Every manager said he was still working there. The automation was acting in error, he should have been paid. Even if a HR and finance manager had to sign off on a check.
>I don't understand the non payment of wages.
Understandable, given one of the tasks of the manager "included renewing my contract in the new system." The manager had to set his contract up on the new parent company's HR/Finance systems, from where future payments would be made. Thus as the manager didn't do this, no monies would be paid.
As to why no back payment was made subsequently once all the evidence had been gathered, that is a valid question to ask.
I had something similar to this but on a much smaller scale. In a retail business I worked at employees were given privileges based on their job rank. So a bog standard sales assistant could do sales but not refunds or store credits. To do those and some other functions on the till you needed to be at least the rank of manager. Your employee card was given these privileges and HR had to give the rank for the card to be encoded. The problem was that a manager was hired for a store in the arse end of beyond and his card was only given sales assistant rank. He only realised on the second day on the job when attempting to process a refund. A call was made to head office to rectify the problem but the IT bloke who was in charge of provisioning tills/cards was away for two weeks.
Suggestion for a quick fix was to use the card from the previous manager which they still had at the store. No luck there because the IT bloke had obviously had obviously automated his processes to allow for people to leave whilst he was away. So the manager was left high and dry for two weeks and a note had to be put in the window and by the till explaining the problem.
Writing script triggered by an email on something this critical is below stupid. The correct procedure is is HR should send out an email directly to the sysadmin and security to cancel accounts, badges, etc. when employment ends. The sysadmin should be using the termination email to the employee as it may be sent prior to the official last day depending on the circumstances.
Writing script triggered by an email on something this critical is below stupid.
"As it turned out, some time-saving sysadmin had written a script to automatically shut out an employee with the trigger being the official employee termination email."
It would seem the "correct procedure" was followed, just that there were no human checks to confirm that the procedure had been correctly initiated. Thus HR should had had the manager approve the sending out of the HR termination email - prior to it being sent, with no response from the manager resulting in an escalation.
No, "correct procedure" was not followed, even if, as is unlikely in any law-compliant organization with even halfway sensible management. Job termination is an administrative decision to be taken by a properly authorized manager. Follow-on action like account and access card cancellation might possibly be scripted, along with other matters like automatic preparation of a final check including things like severance or accrued vacation time pay if applicable.
Something of a rare bird.
The scenario of an organisation where middle management do absolutely nothing when a temp's contract expires is utterly familiar. Its very easy to imagine a desire to automate the process of disabling accounts where a contract hasn't been renewed. I've too often seen a hundred or so completely redundant accounts clogging up the system and providing security holes, or maybe even worse the account being left active and used by successive temps, so the details on the account have no relations whatsoever to the person actually using it.
No doubt the system also generated reports of accounts disabled and so on, but its easy to write a report, hard to get any b*****r to read it. Everything that happened to disable accounts and access seems reasonable to me for a company attempting to run a reasonably tight ship. I also bet there was a rehire procedure - its an obvious enough function, but what's the betting no-one ever studied the documentation and they hadn't actually used it?
This highlights one of the troubles of efficient automation, also exemplified by AF447 and the Uber cyclist slaughter - when people rely on efficient automation it can be very hard to work out when its time to switch it off and go back to manual.
"It would seem the "correct procedure" was followed, just that there were no human checks to confirm that the procedure had been correctly initiated."
Sometimes this happens with entirely human managers and HR. The sheer effort required to get a human being to admit they've made a mistake and stop redundancy proceedings is completely mind boggling. This should have been easier to stop with an automated system...
Given the level of automation, I'd suggest that the system would be able to get the termination date from the email, or that a termination date would entered by a program/HR person, the email would be generated, and the termination process was set to start on the entered date.
In this case, the unfortunate victim was a contractor who was on a time-limited contract with an acquired company, so the termination email was generated automatically, which means that there was no human involved.
The automation actually show that the company had some good security policy.
The problem was that the system didn't allow for human error, so it wasn't able to be interrupted and reversed. Based on the BBC article, another problem may have been caused by the company failing to be proactive and communicating their error to other employees and contractors to make it clear that the company itself had screwed up and not the employee/contractor.
Not the first time that company procedures failed to consider human impact.
See Desk Set (1957), in which EMERAC fires the entire company.
You mean the BOFH series that has been officially published on this very site for years? !!
*facepalm*
>>> The Register: BOFH <<<
"So I'm sure there's a lawyer tooling up right now for the improper dismissal suit."
If he was on contract for services* there would be terms in the contract for termination.
* Which seems to be the case as there was still a agent pimp recruiter involved 8 months after he started.
It does not appear that Mr. Diallo was dismissed, improperly or not, despite the fact that he was prevented for three weeks from performing his contractual duties. The article states that after the problem was resolved he elected to terminate the contract and seek other employment. He fairly clearly is entitled to his normal compensation for any day he tried to go to work, and probably for the entire three week period. He also ought to get a bit more, along with a public (and private) apology.
And the company needs to act to correct the system and as far as possible to ensure that such errors are not repeated, possibly including some actual employment terminations.
On the plus side, this company did an extraordinary job disabling access. I've worked at a few places where enabled accounts for long gone employees was commonplace. On the negative side, the system should have escalated the issue to a secondary or tertiary individual when the contractor was eligible for renewal but their paperwork hadn't been finalized. Also, it sounds as if the system lacks a verbose auditing system for management when it does axe a worker. Time to generate some preventative action item reports...
Our system sends out emails to both the employee and his boss 2 weeks in advance, warning that his termination date is nearing, and that his account will be disabled on that date.
So far it has resulted in one manager thinking he was being fired, and quite a few employees calling in to IT(it's an email. Of course they call IT instead of HR) because their manager said he would extend their contract, and even had the paperwork done and signed. (But hadn't yet sent it to HR to update their DB)
I got overpaid by the payroll system. I complained as I didn't want the HR nazis hassling me later. It was quite a lot of money.
They said it was right.
I knew it was wrong. I had evidence it was wrong.
They disagreed in writing, saying the Payroll machine didn't lie.
I kept the cash.
I got overpaid by the payroll system.
My experience balances yours, then. I wasn't getting paid as a contractor after having transitioned to a new company when the contract was awarded to them. It was a chaotic transition, so I figured that I could live through a few weeks and they would sort it out and give back pay. I had filled out all the paperwork and been sent offer and confirmation letters. My manager had asked up the chain and everyone said everything was sorted... until the next pay day came and I still didn't get paid.
HR had totally screwed up and not entered me into their system. According to them, I was not legally an employee. They were quite panicked about it too as I was the only person at the time who could perform the role and they did not want to admit to the government they had been allowing someone who was technically not their employee to access government systems.
They eventually gave me back pay and a reasonable-ish bonus, but the damage had been done. I had become convinced that the contracting company was incompetent and had other issues with the position. I found another job somewhere else. A shame, too, as I thoroughly enjoyed the work and the folks I supported.
>They were quite panicked... they did not want to admit to the government they had been allowing someone who was technically not their employee to access government systems.
I bet their panic was nothing compared to the company I worked for, who only discovered on my exit interview that they did not have a signed copy of the Official Secrets Act or a completed security clearance for me; I had been working on the site for 18 months and had had access to some 'interesting' projects...
"That they did not have a signed copy of the Official Secrets Act"
the OSA is a bit of a joke really.... I had to sign it a couple of times, once in my very first job, we did some contract work for Plessys/BT when they were developing systemX and another time working at Harwell labs...
the problem is that if you were to reveal anything that came under the OSA and they were to prosecute you, then that secret would become a matter of public record...
I believe, but have no evidence, that it was more effective to set the spooks on you to cause you problems than it would be to admit to the secret and send you to jail...
The OSA may be a bit of a joke as many infringements are misdemeanours with penalties of a fine or a short custodial sentence. If you really annoy the powers that be, they will try to prosecute for conspiracy to breach the Act. The conspiracy charge is much more serious and can result in a prison term of more than 10 years.
I worked for 2 years integrating two large financial services companies as lead developer/support engineer. I had low level access to hundreds of servers and major accounting systems. During the migration itself I had to support both sets of systems.
Eventually I was offered a permanent role in the new organisation.
They said I would have to get a background check, credit check, do a test etc.
Word back from HR was "It would be a bit embarrassing for us if any of these checks failed, given what your role is..."
I thought this was hystetrically funny...
> He [ the chap's ex-manager ] was to work from home as a contractor for the duration of a transition. I imagine due to the shock and frustration, he decided not to do much work after that. Some of that work included renewing my contract in the new system.
> the non-renewal of the contract – requiring human intervention – led to the termination email, which led to that employee's key card being disabled, and their network access cut off on each system that they had privileges on.
So basically the engineer in question was on a short contract that wasn't renewed. When that contract expired the system shut him out. In an example of life imitating art imitating life, I recall an episode of Better Off Ted that dealt with a similar situation.
"So basically the engineer in question was on a short contract that wasn't renewed."
This conflicts with the report that he was 8 months into a 3 year contract. It sounds more like this was a failure in a manual procedure to transfer the data over to a highly automated system.
>So basically the engineer in question was on a short contract that wasn't renewed.
No from the article, the guy's manager was tasked with the transfer of contract details from the old system to the new system and didn't do it before their employment/contract was terminated.
As the guy was on a contract that extended beyond the manager's, the result of the manager's inaction resulted in non-payment and thus breech of contract. If the BBC version of this story is to be believed, I expect the guy took advantage of this situation to effect an early termination and find a new client.
In most big companies I work for as a contractor, the contracts are 1 to 3 months long, and can be renewed for a total duration of up to 3 years.
After that you have to wait half the length of your stay before being able to come back.
Ohterwise the company could be compelled by the syndicates to hire me.
Leslie Thomas's novel "Orange Wednesday" revolves round a soldier who is the sole nominal representative of the occupying British army in a small village in Germany. Over several years the army system has lost track of him - except that he still gets paid and his supplies arrive regularly.
A similar thing happened to me leading up to my retirement after several middle management re-organisations. One day someone with an administrative role rang up to ask which project I was working on. This was a puzzle as I was still doing the same company-wide support job as I had for many years. I later heard that a senior manager in my nominal department eventually said "I thought he had left already!". Left hand - right hand.
AC still believes the widespread IT myth about "Requirements".
Make yourself comfortable, allow me to explain.
The functional density of tightly written software code is typically about an order of magnitude higher than the 'Requirements' it embodies. In other words, a page of software might embody functions that would need about ten pages to fully define. I once wrote a one-liner demo that would need at least a full page to explain.
So if you've got an application that's about the size of a magazine, then the disciples of The Church of Requirements had better have prepared a telephone book size document that wears out the word 'shall'.
Here's the punchline: Nobody can afford this.
...unless they explicitly invoke DO-178, and explicitly and intentionally decide to allocate at least 10x the usual budget. If you're doing DO-178, you'd notice. Everyone else is just paying lip-service and just pretending. That's the honest 99% of so-called Requirements Management.
So, almost always, the coder needs to interpolate and extrapolate. They must silently assume the other 97% of the unspoken requirements. Which is why it's best if they're clever. If they're thick, they could still assemble DO-178 code as directed, until they're replaced by Requirements Compilers.
Most coders, working in the real world which isn't DO-178, need to be very clever, and understand the real world. Their bosses need to understand this. If they point to inadequate requirements, most often that's admitting that they're not clever enough and should transfer to the spoon fed DO-178 world.
Requirements Management is either like DO-178 and you'll certainly notice, or it's a half-assed lip-service and you'd better have coders with actual life skills.
What's horrifically frightening is that so few people understand all this. Almost all of you would be shocked by the above explicit description, while hopefully most will immediately recognize its general accuracy.
> AC still believes the widespread IT myth about "Requirements".
IT myth my arse. I did requirements as part of my MSc and have two years of experience as a requirements engineer, all on the back of previous twenty years of professional experience.
More than half of my time was spent talking people out of nonsense¹ that they thought was the dog's bollocks but at the end of the day would have come back to bite them.
About filling the gaps in the requirements, you are indeed correct. That's why a) you need programmers who are not just competent but also have been properly briefed on the big picture and what the system is trying to achieve (taking them out there and spending a few days with the actual users of the system in their actual environment really helps in my experience, again assuming skilled and motivated programmers²), and b) the requirements team has to be involved in testing also, to make sure that what comes out does not contradict the spirit of what is being sought through unspoken requirements.
So no, requirements engineering is not about writing up fire and forget documents and passing on the bucket. The project manager (incidentally, I also have that t-shirt) has final responsibility but at the end of the day it is the requirements people that gets paid specifically to make sure that the thing does what it is supposed to do, doesn't do what it's supposed not to do, and doesn't screw up too badly in other ways. As per the footnote, a big part of the job is dealing with personal interactions and incomplete information and still making sure you produce the right product. Excuses do not get you there.
¹ Nowadays they include psychology in the syllabus, which appears to be actually helpful.
² Such as I have always had the privilege of working with, here in the continent.
AC offered, "IT myth my arse", and then went on to more or less agree with my points.
"About filling the gaps in the requirements, you are indeed correct." Yes, the gaps that I mentioned. Those huge gaps occupying that ~97% empty space where complete Requirements Management should be.
Rebuttal my arse; you're agreeing!!
Because the "Requirements" are "Business Requirements" not "Software Requirements".
They describe what the Business wants to have (and might or might not get because there is no guarantee that any of this fits into an budgetary envelope or is even consistent in the first place).
Describing the Solution and what it should is something else entirely and indeed, the completed Software Requirements would be a fat mix of informal documentation, some diagrams that could be related to something once seen in a SysML crash course, and commented code with unit tests.
Something similar happened to me once in the middle of a system build. I had a dozen machines imaging from the server and suddenly the imaging all fell over with "server not found" type messages. I tried restarting them only to keep getting "invalid logon" messages. I was munching at a sandwich wondering what to do next when my site manager wandered past and said: "I've just been told your contract ended last Friday". Oh, nobody had told me. Well, ok then, it's a nice July day, went home, emailed my agency and ensured I got paid for the 2.25 days work I'd done.
I had a similar thing happen to me. I was a contractor employed on a fixed term contract. The manager set the contract to expire at the end of the financial year. Automated e-mails were sent to the manager 30 days, 14 days and 7 days before the end of the contract with the option of extending. My manager verbally confirmed to me that I would be working on the End of year processes for payroll. He, however, didn't respond to the e-mails. (I didn't even know about the "end of contract date" in the system as it was purely an admin thing that was required for all contractors).
I come in on the first day of the new financial year and login, all Okay. Around 10:00am (Midnight GMT) I start getting messages that I don't have access to shared folders, my e-mail stops receiving e-mails and other "strange" events start happening. I log a call with the helpdesk and they come back with the message that I have been terminated in the system. My manager starts frantically trying to get me back on the system as I am critical to the End of Financial year process and need access for the company to be able to meet some legislative deadlines. We were advised that we couldn't stop the process once it had started. All we could do was wait for the next issue and have my access manually restored. Fortunately I could have my access reinstated once the process had moved on to the "next step".
We spent the next 3 weeks fixing my access as different issues came up. That manager never again ignored the "End of Contract" e-mails...
Something similar happens to me every 2 years, when my contract "expires". Inevitably, whoever was supposed to handle the renewal simply didn't, so when I come on-site in the morning, my badge won't open the gate. But it's so common that Security just gives somebody a quick call to verify I still work there, reactivates the badge, and I'm fine for 2 more years.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
