Blog Home  Home Feed your aggregator (RSS 2.0)  
Rays Development Blog - ErrorHandling
A look into the mind of a VB Developer
 
# Thursday, 14 October 2010

I just found this so funny I had to share it. Although things like this have happened to me in code before so I probably should not be casting stones, I do still admit that I find it funny and point an occasional finger and giggling allows me to vent sometimes :)

I received an email the other day from a company (nameless - unless you happen to recognise the email :) )that provides a daily supply of white-papers and other technically oriented and marketing type documents for us geeky folk to read in our volumes of spare time.

I just found it sooo funny when I got to the bottom of the page and read the last item on the list...

(website link and company name clipped to protect the innocentgoofy)

I'm really sorry, but I have to admit that I spent a good 10 minutes laughing at this and finding great joy for some reason.

So, let this be a lesson to everyone out there, and me too. People WILL laugh at you for making a goofy mistake. How do you want your marketing efforts to be remembered?

Hmmmm...

Maybe they did this on purpose?

Nah... I doubt it...

Note: Yes, the actual link to the document DID work, and it was actually pretty good.

Thursday, 14 October 2010 21:07:56 (Eastern Standard Time, UTC-05:00)  #    Comments [1]   Customer Interaction | Error Handling | Expectations | Requirements | Testing  | 
# Saturday, 11 October 2008

Recently, in one of my many quests for knowledge about the good old NNTP protocol (be on the lookout for a really cool Usenet news reader to be released by Enterprocity within the next few months) I was pointed towards something called Postel’s Law, also referred to as the robustness principal.

 

In a nutshell the law is simple. It states:

 

“Be conservative in what you do, be liberal in what you accept from others.” – Jon Postel

 

You can see it for yourself right here at the bottom of page 12 in RFC 793 (TCP).

 

Since I am embarking on my new role as a Senior Software Engineer next week I thought that me getting pointed to this quotation form Jon Postel was quite apropos.

 

This is something that I have seen so much of over the last few years as my old role as a Senior Applications Engineer, both in the products that I supported as well as in the products that I helped others build. Many times companies can get involved in a finger pointing match over who owns a bug (us or them, it’s not OUR fault) or if something is even a bug or not. Many times engineering would point to a message we got from another component in the users solution (we did VoIP Gateways talking SIP so in these cases is was SIP messages) and said that the message was malformed in some way, and this was why our stack threw it on the garbage heap, or leaked memory, or threw an exception, or dropped a call, or some other undesirable behavior that caused someone to pick up their land line and call me.

 

It all boiled down to Postel’s Law. The third party SIP stack that we used (no names here please) was not very robust at all in its ability to take in things that were not 100% to the RFC. It was a good stack that did its job and had a good team behind it but when it came to handling SIP messages, it was very picky to say the least. One message that was not a complete verbatim to the ABNF used in the RFC and that message was ‘wrong’ and the behavior was indeterminate. That and the fact that there are some really nebulous areas in the RFC that did not help, made it look at times like the product had some serious issues, and in my opinion it did, from a users perspective. Taking this to another level, many of these malformed messages were in message headers that our product did not even care about, that just ended up adding insult to injury there.

 

In user land, people don’t care about all the stuff behind the scenes; they just want things that they paid for to work. Add to the fact that other products that may not have been better in all other respects did not have a problem dealing with these errant messages, and our product became even more suspect in the eyes of the customers. All engineers need to understand that a customer’s perception is reality. Even if YOU, as an engineer, know that the problem is really NOT with your product but with the other one, or a bug in a third party component that you use in your system, the customer sees an exception thrown in YOUR product or poor behavior in YOUR product and not the others; your product is the one with the problem.

 

So, this is just gentle reminder to all engineers out there (myself included) that not only do you need to validate all input to your systems (a good thing that some of us may take way too far) but you also need to decide HOW you are going to act when you detect that bad input. Throwing an exception when you are the upper layer, right next to a human user, may not be the best (be on the lookout for a posting on the use of exceptions :) ).

Saturday, 11 October 2008 00:54:58 (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Design | Error Handling  | 
Copyright © 2017 Raymond Cassick. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: