The Danger of Dollar-driven Development Decisions
Photo by Karl Hedin on Unsplash
The Secret Developer thinks that the whole deck of cards might be on the verge of collapse. Software development decisions are so driven by the short-term and the dollar value that things turn out for the worse.
In the case of the British Post Office scandal things turned out much worse than they might because of the penny-pinching attitude of Fujitsu who employed the software developers and delivered the system.
“This story isn’t just about bad development decisions (although those happened in droves). This is about the structure of work and why our development practices need to change, and fast.”
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 of 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 you may not be surprised that a major software project might overrun and function poorly.
The Horizon software system incorrectly showed money missing from Post Office accounts, it frankly couldn’t add up (which you’d expect to for a financial system). Although the issues were well understood by the developers, this problem failed to be fixed so that they could release the software and Fujitsu get their fee.
“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, nobody died in the projects I worked on. We just were not capable of getting the requisite quality software out. The business owners put great pressure on us to get releases out though. It seems that the same issues happened to this famous Horizon project in the UK.”
Money on Release
Developers knew a problem was brewing with the Horizon system that would cause so many issues within the UK Post Office.
‘Everybody in the building, by the time I got there, knew it was a bag of s***. Everybody.’ SOURCE
They didn’t just keep this issue private. The error handling needed to be rewritten but devs were told the company didn’t have the resources to fix it. The Post Office as a corporation rejected the system, only to accept it into production accepting iterative improvement to the crucial parts of the system.
The rumor is that without payment Fujitsu would cease to be a going concern without immediate payment so needed the system to go into production at any cost.
“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.”
This could be one reason that the quality of the development resources was called into question at the time. The best developers would not want to be part of the project and would either leave the project or the organization entirely.
“I can fully believe this one. On every software project I’ve worked on, some devs simply don’t know what they are doing. ”
Software Development Should Be About More Than Money
“I’m not someone who thinks that passion in the broadest terms of the word is a good way to motivate developers.
Yet I think if you’re doing any work just for the money, you’re likely to do a bad job. In this case, the project seems to have been awful and it got pushed to production without being close to ready.
As developers, we should say no to decisions like this. They aren’t right and we need to make sure our businesses succeed for the right reason. “
Conclusion
This is 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.”