It’s common for early-career programmers to write code for “the happy path” – code that works when everything goes right. But you need to have code that will be prepared for when things go wrong.
Users will type letters in textboxes that only expect numbers. They’ll put numbers in textboxes that only expect letters. The disk drive you try to write a file to won’t have free space. The network will go down. The database won’t be available. Hackers will try to do all sorts of things to any website you create.
There are a few of the hundreds, or thousands, of things that can happen to the programs we write.
Our programs need to handle these problems, often called “software quality attributes” or “software -ilities” (since many of them end in -ility).
This requires balance. You can spend the next ten years making a program “perfect”, when it might have only taken six months to release something that’s 95%, with the remaining 5% not being important.
A typical way to make your programs more robust is to “never trust external input”. For example:
– Assume files you import will have their format change without anyone letting you know
– Assume any external resource (network, database, web service, etc.) will be unavailable
Oftentimes, your program won’t need to correct the problem. It may just need to give a clear notification that a problem happened, and what to do to resolve the problem.
There are times when we don’t need to put in the effort to make our software high-quality: for example, with a small proof-of-concept program. However, watch out for the times when you demonstrate a proof-of-concept program to a manager, and they think it’s ready for production.
You need to make it very clear during the demonstration that there’s still a lot of work that needs to be done before the program can go to production. But, even when you try to be very clear, people tend to understand what they want to understand – and they want something that can go into production today.