Programs do not acquire bugs as people acquire germs, by hanging around other buggy programs. Programmers must insert them… Harlan Mills
Software breaks all the time: booting issues, corrupt software and files, crashes etc; nearly everyone has had a close shave or two with fragile software. Can programmers write ‘perfect’ fault-free software? I presume a trip to Uranus would be much easier, here I come NASA! :D.
A program’s complexity scope is way too large to fit in a programmer’s mind. It is difficult (nigh impossible) to ascertain a program is valid, in fact it is extremely difficult to know the number of errors in software. Here is a simple example, exhaustive validation of an 8 character field would require checking 26^8 combinations (assuming only letters a-z are allowed). Real-life programs contain typically have larger problem domains.
Since achieving a utopia of bug-free software is not feasible, we might as well set our sights on something much more achievable – producing robust software. Robust code doesn’t translate into perfect software; however it tries to behave ‘nicely’ when things go awry – i.e. it does not wipe your hard drive.
Here are a couple of suggestions for writing robust code:
1. Don’t trust anything that comes in from external sources – sanitize, validate and then confirm. You can also log suspicious activity and have default fallback actions.
2. Remember Murphy’s law (“Anything that can go wrong, will go wrong”); that 1 in a 10000000000000000000000000000 chance event needs to be handled even if you ‘think’ it’ll never happen. This is software + humans, remember the large complexity space?
3. It is essential to write simple, flexible, extensible code; if changing one parameter breaks the source then you need to refactor. Also keep in mind the YAGNI principle and do not write unnecessary code just because you feel like it.
5. Write the least amount of (clear) code needed – The less code you have, the less the complexity (and the number of likely bugs/errors) and the better for everyone.
6. Keep cyclomatic complexity low, the fewer the number of executable paths in your program the simpler it is.
7. Test your code and when ‘bad’ things happen, remember to exit gracefully.
Do try to write robust code; you’ll save yourself future worries, impress your customers (which likely translates into lots more $$$ from future referrals) and improve your craft.
This post was motivated by my fascination with the ext file system…. I keep having boot issues with my Ubuntu installation whenever I force it to shut down – this causes the ext file journal system to end up in an unclean state. While in this state, the operating system does not load and I keep ending up at the initramfs prompt. A live disk, some tweaking at the terminal (e2fsck) and the operating system is good as new again.
CodeKraft 
Your Mills quote probably predates practical AI programs which can potentially learn bad habits from their “peers” or users. Note the spectacular fail by somebody’s twitter bot recently which became a total troll/racist by “learning” from its wondrous environment. Better coding saves debugging costs which can be a major source of overhead cost. You can’t usually bill for the time it takes to fix your own mistakes. When I worked at a bank, fault tolerant systems were just coming into use. For the vendor who supplied the software system I worked on, I had to coin the term “Fault Ignorant” because when something went wrong it would often just keep going compounding the errors it was making. Fun times.
LikeLike
Well the AI scenario might be said to be different – that was just an unexpected outcome that no one foresaw.
The ‘fault ignorant’ scenario is quite funny. I can’t imagine how challenging debugging such multi-layered bugs would be.
LikeLike