Building a business and a pipeline is not the same as building a technology. Transitioning from a cool project to a successful product is far far more than meeting specific technological milestones.
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.
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.
Viewed 123410 times by 6440 viewers