I have a story about a contract job I did for a major company in the valley. I gave a bid to write an installer for their software/hardware product for something like $4000 they asked if I could do it for $2000. I replied that I could do it if I never had to install or test their product or the install, that they would do all testing. Incredibly, they agreed. I realized they were insane but I wrote the installer and it went out with their product and after a couple months they discovered it would not upgrade certain versions that existed that they never told me about. They wanted me to fix it for free. Today I would just walk away and would never have accepted the contract to begin with.
There is always a balance on how many exceptions one should handle explicitly in code. Some exceptions you can anticipate, but others you cannot until you are surprised by some data or input. You can spend forever adding exceptions and error handling. Now when I develop I do not spend a ton of time making the processes I work on bullet proof. I try to make them fail hard and not hide problems. I also try and anticipate more cases than the business requires at the moment and try not to hard code too much but I also try and not go to far in that direction.
I try to strike a balance between robust, future proof, scalable and the business needs for low cost immediate gratification with very little testing.
One more story: the last time I was an actual W2 employee at a company I converted to contractor over the fact that they would not allow me to improve code unless the business requested it specifically and then announced they were moving to Oracle and would depend more on outside contractors. I decided I would once again become one of those outside contractors; one of those people who do what the business asks and not worry so much about the long term health and maintainability of systems. It is still very hard for me to walk that walk, but I am trying.
One of the big dilemmas is in the absence of testers because there are no dedicated resources and the business is stretched too thin, the developer is asked to also do a lot of the testing. Developers doing the testing usually means a bunch of not to hard to find bugs that the developer was blind to, but that’s current reality in many businesses. In the absence of that I think evolving code and systems over time to more perfect solutions is the way to go. If you play this game you have to be able to respond quickly to fix bugs because you are testing in live. But that's a tough game for contractors who maybe have moved on to other jobs or projects. The idea that anyone can make perfect upfront decisions in todays business world is silly. Business today likes the agile method of quick delivery. They don’t like that it then has to be continually touched indefinitely, so they live in denial about what it takes to support a custom solution and bounce about thinking now they are finally ready to design a perfect solution.
Businesses have to decide if having a cranky old developer that knows their code and systems is worth more than the ability to blame the past and start fresh with a new consulting group or product that promises to leave all that legacy angst behind. My opinion? Hire a second cranky old developer and lower the manager's salary.