Bad Code Can Destroy Lives
Have you ever been told to leave bugs in a production system? You aren’t alone. The Secret Developer certainly has, and so have the developers of the doomed British Post Office project Horizon. The latter produced real-world consequences of jail time and lost lives, and The Secret Developer believes there are lessons to be learned here for software developers worldwide.
“Fixing bugs and calling out issues needs to be part of our jobs as software developers.
I’d like to explore when and how this fails to happen, and why we are all at risk being part of disastrous projects that can even contribute to ending lives.”
The Story
The British Post Office is a centuries-old Government corporation so it might not be surprising that a digitization project might overrun and function poorly.
The story that has rocked the British establishment is that the Horizon software system installed at post offices incorrectly showed money missing from accounts and then the corporation used its financial and legal might to convict and bankrupt hundreds of people who ran branches.
The story that has shaken the software development community is that devs knew the problem, yet this was not fixed.
“I’ve worked on some dodgy projects in the past. I think a software shop I worked at, took a Japanese travel agent to the cleaners with their implementation of a hotel booking system.
Still, I think nobody died. We just were not capable of getting the requisite quality software out. But we didn’t KNOW there were bugs and just leave them.”
The Bosses
It turns out the corporate Post Office knew the system couldn’t add up. They rejected it in September of 1999, yet Fujitsu UK started rollout in October 1999 with the precondition the system would be fixed during post-delivery product development.
The story is that the Fujitsu could not afford to delay the system, and so rolled out accountancy software that could not be relied upon.
“It’s the ‘we can’t afford to make it better’ answer. Sure, if you can’t afford to do something properly you have to pick up the cost later.
This sounds like my bosses telling me that tech debt doesn’t matter and we can do it later. It never gets done.”
The Developers
It turns out that developers knew a problem was brewing with the shoddy system.
‘Everybody in the building, by the time I got there, knew it was a bag of s***. Everybody.’ SOURCE
Developers did raise the issues. They were told it was too expensive and time-consuming to fix. The error handling? Needed to be completely rewritten and they didn’t have the resources to fix it.
“When I worked for a large IT outsourcer they had a large number of ‘red’ projects. These were contracts that were signed that would never make a profit, so were under resourced and stretched.
The best developers would avoid working on those projects, so they had few resources and even fewer good resources.
This sounds like the situation with the Horizon project. I haven’t ever worked for Fujitsu (I think I interviewed once) but I’m super happy I didn’t join them now.”
Not only that but the quality of the development resources was called into question at the time.
“I can fully believe this one. On every software project I’ve worked on, there are some devs who simply don’t know what they are doing. ”
It’s not just devs
The helpline set up to assist postmasters with the new system told each and every one of them who had a complaint that nobody else was experiencing these issues.
“This sounds like our IT support actually. They lock out devs who have worked for 6 months. Support? That makes me laugh.”
What Software Devs Should Learn
Software developers, should they become a whistleblower and call time on bad practices at their employer?
“Any software developer worth their salt should think about where their limits are. At what point are you likely to stand up and say ‘enough’? If you don’t have a limit you should check in with your own moral compass.
The thing is everything in software development is really answered by the catch-all ‘it depends’. Here are the things that it depends on.”
Balance these
Ethical Responsibility
Sometimes you’ve got to fix it. Speaking out can be about you doing the right thing. Sometimes it means disrupting the status quo and annoying people, but sometimes that is worth doing.
“Doing the right thing sometimes is tech debt. It’s sometimes saying that processes are wrong. It’s sometimes saying this project is broken.
I’ve done all of those things in the past, but here’s a list of why/why not call time on the mistakes our companies are making.”
Protecting the Public
As humans, we have a responsibility to our fellow man. With great code comes great responsibility.
“Doing the right thing is thinking of others.
I’ve never done that is the past”
Improving Industry Standards
Defuse those bombs, one truth at a time. Just get it fixed for the good of all of us.
“I’ve definitely not done this one.”
Career Repercussions
Let’s not sugarcoat it blowing the whistle can make you the office pariah faster than you can say “git push.” You might find yourself on the receiving end of a cold shoulder or, worse, a pink slip.
“I’ve definitely not done this one. I’m more of a complainer.”
Legal and Financial Risks
Speaking up isn’t just a social gamble; it can be a legal minefield. The road to whistleblower fame is often paved with lawsuits and financial strain.
“Going to court? No not me.
However, I have told internal auditors all sorts of things. I think that doesn’t make me bad.”
Personal Stress
The life of a whistleblower isn’t all retweets and high-fives. The stress and scrutiny that come with it can be like debugging a legacy system at 3 AM — overwhelming and lonely.
“Overwhelming and lonely. Sounds like my life.
Anyway, I guess I can’t be more unhappy at work so this point would not carry weight for me.”
Conclusion
Unlike many of the more fun articles, The Secret Developer writes about hoodies or dogs, this one genuinely means something.
It’s about responsibility and how we hold ourselves to moral standards as software developers.
“It’s important to do things for the right reasons. Yes, even when creating pull requests we should be doing it for the right reasons.
If you are working and something is hideously wrong you should say something though. It’s your responsibility to do so.”