A good developer hates to see an unhandled error in his or her code. If a user sees an error that tells them what line your code failed at, this is not only a potential security risk but also a major point of embarrassment. Bad developers think itâs totally acceptable.
I have this kind of argument all the time– âWhy donât you put an error handler here in case the calling code (or user) enters some bad data.â I get the same response ever time, âBut, how often will that actually happen.â I have this conversations over and over. The only thing that changes is the person Iâm having the conversation with.
When youâve coded for lots of different companies, you start to learn how common this is. You have a few very dedicated developers who cater for errors I canât ever see happening, but you get a lot who are just winging it and stop coding when their work reaches bare functionality. When you see a news story about how a big site was hacked and all their data compromised, itâs not all that surprising. A site can look very professional on the outside and be very shaky underneath.
I was trying to order some travellerâs cheques from American Express today. You may have heard of the company. Iâm sure they spend top dollar for software developers. Iâm still not sure what I did to get this (I wasnât looking for bugs in their software), but I got a big ugly ColdFusion error message:
The error is a standard IIS-delivered unhandled exception error. I know the lines of code that failed. I can even click on a link to see a stack trace. So, you know, I guess itâs embarrassing for the developer (or at least I hope so). But the bigger issue is that I canât trust the site any more.
Somehow, I entered a zero where I should have had a value (and the code is trying to divide by zero), but I honestly donât know where it was done.
Do you think Iâm entering my credit card details after this? I mean, what else are they not paying attention to?
Actually, it looks like American Express sent me to another site (with AmEx branding) called FX4You. But still, it reflects badly on American Express.
The ugly truth of software development is that there are loads of standards, but not many of them are adhered to. Testing always goes out the window to fit delivery deadlines. Code reviews are non-existent in most organisations Iâve worked with. The flip-side is that projects loaded with too much bureaucracy frequently fail to see go-live. There is a happy medium and it is difficult to find.
Back in 2000, when everyone was going crazy about e-Commerce, I was working for a small company looking to build an online shop. One day, I mentioned that I did not trust most websites with my credit card details, someone started to poke fun at me– âIsnât it ridiculous that our web developer doesnât trust buying things on online?â But, even then, I knew how easy it was to leave security holes open in software. Just because I took precautions in my code, I knew not everyone else did. Now itâs almost ten years later and I think most people are more wise to security, but I still would take a site that uses Paypal over a custom-built credit card engine any day.
Maybe I can buy my travellerâs cheques through the American Express site safely, but I wonât risk it.
Nice one! I totally agree.
I have an Amex credit card and use that website. But I will not be so critical. I prefer to believe in a banking web application like the Amex B2C website, there are a lot of things other than code breaking up because of developer oversight. It can be configuration, maintenance and a host of other things.You are right in one aspect, in the Western Hemisphere, I have never seen an organisation do destructive testing as in entering data that they are not supposed to, creating configurations that are pure garbage and that like that though never exists in specification and yet attempted with the sole intention of observing the behaviour of an application under natural or otherwise stress.I have a friend who now lives in Canada and when he was a tester, he would submit an order and then pull the network chord or sometimes the power cord to see how the system would cope with such situations or when it came back on….it infuriated developers but destructive testing was part of the project plan(we were in the same org around that time).Result is top notch products.What we need is a proper process maturity and any developer who asks a question "How many times will that happen" should be read the roits act or fired. Statistics is not his/her job. It is his/her manager's job. His/her job is to produce good quality engineering.I will not tolerate such questions nor should any project manager/client. Anyway, I will stop my rant. It is easy to get lost on a Saturday night at 1:45 AM, more so.