Saturday, October 24, 2009

IMiserable <T>

Before you think otherwise let me clarify that IMiserable <T> is not a new generic interface introduced in .NET 4.0. As I climb up the stairs as a developer, every passing day, there are certain things that simply make my life miserable day-in  and day-out.

I hereby attempt to list down the top 3 things that I believe are a mess for developers at large. It’s amazing how most of us (if not all) find ourselves hooked up eradicating these miseries per project, per day basis.

  • #3: My Code, my browser: I have been developing web applications for around 3years now and I simply couldn’t understand why I am supposed to make my pages compatible on all major browsers. For people who might say “why not”, here is my defense: Web is everywhere and the way to access it, the ubiquitous browser. Give me 1 reason as to why as a browser vendor, you need to make your own rendering decisions? Why can’t differences be only in terms of the underlying performance engine and client script execution engine? Why do u need to render tags differently, be it alignment for certain tags or other rendering decisions or awfully at times, some completely new names for similar elements across the DOM (supported across the browser with different names for same elements)? And to add insult to injury, you guys can’t even maintain compatibility between your own versions (and someone asked cross browser compatibility).

    Just because I don’t have a browser of my own (Vaibhav Explorer or VaiFox or Vaifari), am I supposed to tolerate this misery?

  • #2: this.Validate(): Did it ever cross your mind that if you were not supposed to write validation code (for all possible combinations of mess that the user can create) how much time, LOC, and execution optimization you might have gained? Just recently I was coding a Registration page with something around 30 fields with good numbers of Checkboxes, RadioButtons (in various groups) and plenty of DropDownLists and TextBoxes. And guess what, each dropdown was supposed to have a “Select” item at the top of the list and awfully enough, all fields (except checkboxes) were required. So selecting “Select” in a DropDownList wasn’t allowed and I was supposed to validate and prevent the user from submitting “invalid” input. This is the too common misery for all of us developers out there. And yes, did I mention that I was asked not to use the ASP .NET Validator controls (for some cynical reasons which only my PM can answer). And needless to say, every failed validation would prompt an alert box (in client script) with a custom prompt message. Trust me, and you would agree, roughly 60% of LOC of that page was validation script code. And yes, the ultimate saver of any developer Mr. Copy & Paste couldn’t help me beat the frustration out!

    Why can’t the world (denoting my dear clients and their honest and well-intentioned users) just provide valid input in the first place! I know it’s impossible but just imagine a world with no validation where every byte of input comes from a trusted source, is perfectly what I need and needless to say, side-effect free!

  • #1: Works on my Machine: This is undoubtedly the numero uno of our miseries! How many times have you found something perfectly executing on your local workstation and simply freaked up on the live server. And the first reply that comes (by default) when the PM enquires for the crash is: “It works on my Machine”! As if you didn’t knew that the client didn’t pay to browse “localhost”. It’s humorous how even seasoned developers cite this reason. And I have self witnessed this so many times that while my fellow dev was freaking out I was almost insane with an internal laughter (an external display of laughter will only dispose me and make me garbage collected by my company).

    And you would agree, the maximum time this misery appears is when it’s time for you to buzz off and the PM being a very respectable, honorable and understanding person, makes it clear that you aren’t leaving before everything is fixed showing absolutely no interest nor intent of lending even half the hand to help you out.

Share your miseries that you feel are worthy of being added to this list!

Debugging miseries is all we do day-in and day-out. Let’s just continue with it (as if there were other options available)!

Happy Coding!


  1. Vaibhav:
    Misery1 is a standardization problem.This is not only true with browsers but many other components as well.This is a major problem in our industry vis-a-vis other core engg. discipline.

    Misery2 is sometimes absolutely required and sometimes over engineered in an ultra defensive fashion.I also do not like ASP.NET Validators..

    Misery3 is a practical problem.As a developer we concentrate on solving some specific problems, one them is my module should do what is supposed to i.e functionality.But there are 10 other factors that we need not think of.For example
    When we code an ASP.NET application the login used normally has administrator access on our desktop.So everything works fine.Then after deployment in server for test we find that ASP.NET process identity needs access to folders where we are reading or writing from...

    Anyways it was very honestly written and nicely written...

    Keep blogging...Please write a post ILoveable<T> :-)

  2. Just a correction
    "But there are 10 other factors that we need not think of" will be
    "But there are 10 other factors that we do not think of" :-(