I recently returned from a trip to Hawaii (my wife and I went to a wedding) to find out that one of my software programs had crashed during a critical time. Luckily for me, enough WORKING ‘duplicate’ reports existed for the data to be extrapolated from the DB and sent to the appropriate department.
However it forces me to pause and reflect. Selah.
Everyone with a CS degree should have learned about the Software Life Cycle. It’s an interesting model that can be viewed in many ways. Basically very few programs are ever written, tested, modified, released and then never touched again. As the only constant is change, and this truth extends not only through our personal lives but into the working world as well – I’m given pause to consider the Software Life Cycle.
Things change. Let’s face it, but what is the best practice for things like software that can change both quickly and significantly. It turns out that my programmatic issue was a DATA issue (compounded by another system recently upgraded unfortunately producing slower access times). But as a Software Engineer (SE) I should be able to deal with that. Or should I?
Who’s job is it to maintain the QA of ‘the code’? Is it my job as the SE to guarantee (which is a dirty word with computers…) that NO MATTER what comes my way the code should be able to stand? Is it the job of the DB engineer to structure the DB in such a way so that many things are not possible – thereby eliminating many ‘required’ checks and error conditions, etc…
I’m not going to propose ‘the answer’ or an answer at all.
Users want stability…and consistency. The SE wants to be able to efficiently generate code to meet the users’ demands. Is there a responsibility by the SE to train the users to use the program correctly, thereby again eliminating much ‘required’ error checking, etc…
As a SE I don’t want to bloat my code with 400,000 checks and re-checks to make sure that every possible condition that CAN exist will be dealt with. That creates as much as 2-3 times as much code – which itself can be buggy. Is it alright that when a users does something REALLY unintuitive and totally against what the program is supposed to do that they get an ugly error message and have to contact me? Is it alright that when someone else’s system has data integrity problems that it can create ugly error screens for my users?
Should the users have to put up with that?
Should we (the SE’s) always have to make sure that even when things go wrong that the user gets sweet and clean messages and everything’s still pretty and happy? Should I be expected to have programs that never crash (or at least crash hard) ?
Well fortunately I have great users and my programs don’t crash often. Users understand that program do occasionally crash. Not everything can be considered beforehand. Sure it’s my job as the SE to keep them from crashing frequently. But with an average of 5 minutes to fix most problems, where is the line?
Where is the line?