Being the Squeaky Wheel

After having an issue with a ZEN product open with Novell Support for over 6 months, we're finally getting some real attention to our problem. The issue relates to the ZENworks Server Management product - specifically, the Ping agent that lets you know when servers / services are up or down. It's acted flaky for over two years, across three versions of product, two hardware platforms, and two versions of NetWare OS.

A bona-fide Provo resident will be here to ensure that neither we nor Novell Support have missed anything, and will climb on the phone with developers in Bangalore, India to figure out what the heck is going on here.

It's good when you can get that kind of attention, but it's bad when you need it. I wonder how many other IT managers feel like they're unwitting Beta-testers for software they've purchased. We feel that way a lot - with all sorts of products. It's one thing for a vendor to tell us "You did it all wrong." We hardly ever hear that. We always hear "You have it right, it should be working." Yet it takes months sometimes to figure out what is broken or why.

I don't know how software with such easy to find deficiencies ever makes it out the door of these companies. My favorite chef, Gordon Ramsay, likes to say "Keep your mistakes in the kitchen." The ability to do that implies that someone - who knows what they're looking at - is actually reviewing every aspect of the product. Just like a chef would.

I'd rather get served a great meal 30 minutes late than to have utter garbage put before me on-time. The mentality that says "meet your dates at all costs, and fix it in a Service Pack" is nonsense.

The mentality should be "get it right the first time, at all costs". 99% of the time, schedules and deadlines are artificial creations in the software development business. Many products are so complex that facilitating a 3-month development and release cycle does nothing but dilute the quality of the product. It's the IP networking equivalent of using a very small MTU setting on a robust backbone. Projects, like ethernet packets, have a minimum overhead. The more payload you deliver under that overhead, the more efficient the mechanism becomes. I'd love to see development and release cycles move to 6 months - especially at Novell.