As programmers we come a across quite often a question: “Is the application safe to deploy?”. I had to ask myself as well sometimes: should I deploy X or Y feature even if there is an edge-case bug in there? Of course later those edge cases are the bugs, that the users find. Even though they aren’t looking for them, but this just shows sometimes how far we get from the way our users would expect an application to work.
Long time ago when someone would say: We can only deploy an application when it is safe to do open-heart surgery with it! I would smile a bit to myself thinking that I’m not coding medical equipment nor aviation software. But as years past and I got more experience working with spaghetti code and legacy systems that I inherited from here and there, my view started to change on this. It changed to the point, where today I would say the same to fellow programmers.
Save time today by cutting corners (e.g. cutting on writing tests for a fix or a small feature) and you will waste 10x more trying to fix it later or add a new feature to it. But if it would only be time that is wasted… but its not just time, it is never only time…
With bad code you will waste credit, clients will not trust your work and will have a fear from either deployment (what will break this time) or from not getting what they asked for (we got A and B, but C will only work if you sacrifice a chicken at a blood moon).
With bad code you will also waste the time of the users, if that user is trying to use your app to actually do their job, then you’re wasting their employer’s money as well.
With bad code you can cause your user to miss their monthly bonus, if you do an app that is used by employers to track employee performance.
With bad code you can also waste money of your client directly. Even if you do a small webshop and if any steps of the checkout or placing the product in the cart is acting badly, then your client will lose their clients.
With bad code you can get someone unemployed - doing an accounting application that doesn’t sum up everything correctly, or misses to add some taxes.
With bad code you can get someone imprisoned, as above bad tax reports can be seen as tax fraud in front of court.
With bad code you can kill someone even if you don’t do aviation or other safety-critical software.
There are lots of things that can go bad in software and while I enjoy making spaghetti code better, adding tests, breaking them down and adding meaning full naming. Every time I look at an app that is 100% spaghetti and I know that there are thousands of users using it daily, can’t help it but some questions comes to my head: “How did this make it out to production? Who thought this is okay to do? How is this still running?”
If you write code that someone will use, then please read the following three articles and take it to your heart. Think of them every time you code something! Even an accounting app can kill someone!
- https://www.dailymail.co.uk/news/article-9502925/Post-Office-scandal-Dozens-staff-today-convictions-quashed.html
- https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/
- https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal - this one is an exception. Here not the code quality, but the quality of the person who done the code knowingly is the issue.
Is your code good enough to do an open heart surgery with it? Would you bet your life on your code?
Top comments (0)