Products versus projects

Long ago I pondered

Projects, inherently, are un-finished entities. There are missing things. There are “un-implemented features” which would be necessary for a product. Like say, an on-off switch, among other things. Products are inherently compromises between design, realities of implementation costs/schedules/complexities, etc. Software developers often get into the endless cycle of tweaking features and improving systems so that they miss target dates. We see this with larger scale projects as well, unless someone adopts the iron-fist rule on adding/tweaking versus shipping/learning/improving $version++. Over the last year, we’ve seen a number of projects that were masquerading as products, missing any number of things, and needing a full on bake-out, improvement of quality and reliability, improvement of UX, implementation of things that are completely lacking. I’ve personally agonized and changed the design many times, of our monitoring code. My latest head-desk inducing thoughts include rewriting some of the data collection logic in node.js. There’s no reason to, and as I am rapidly discovering, node.js is great for what it was designed for. Maybe a bit less so for things it wasn’t. To a degree, this is an application specific language, with some additional bits bolted on. Javascript always was that, and while it extends well, it might not be most appropriate for the things I want to do right at this moment. But this isn’t criticism of node. This is pointing out that I’ve personally gotten stuck in the “lets rebuild this thing this way” versus “lets ship this puppy”. I’ve taken to putting the tools we want to get out there on our git page. But we’ve been dealing a bit with hardware that falls into this as well, where, rather than wait until its perfect to ship (forever), it is shipped early, with a number of (glaring) omissions/bugs. Without mentioning names, one of the disk controllers we’ve used has a nice little firmware bug whereby the identify/activity light simply doesn’t work when you send it a “light me up” SES/SGPIO command. And the manufacturer admits this, with the solution of “wait for the next firmware release”. There are others as well, but it gets me thinking that there are a pretty wide range of products that are half or less baked out there. And any number of projects that should have shipped long … long ago. The recent update to IPMI Console Logger was all about finally getting out the code that needed to get out. Once the code hits the ground, its easier to incrementally extend and fix the bits that need extension and fixing. Likewise, the new Perl modules I’ve developed for manipulating the key-value pairs in /etc/sysconfig/ in CentOS, are things I use/reuse all the time, and I needed to push this out. Those are projects. And they should be released early and iterated often. Harder with products, unless they are designed for that.