I am a perfectionist by nature. Releasing software in to the wild that has imperfections annoys me. For that matter, doing anything that is imperfect annoys me.
Thankfully, there is this little thing called reality that I sometimes get smacked around by and learn from. One of my more recent smacking and learning episodes came in the form of realizing that I am not the only stakeholder involved in the release of software. There are business stakeholders who are deeply vested in the timely delivery and success of a software project. The operative word in that phrase is "timely". There is also another piece of reality that I had seemed to forget in my time here on earth - nothing is perfect (and definitely no piece of software will ever be perfect).
I was speaking with a lead QA guy for my software shop at work about three months ago about a relatively high profile software release that was about to go live. The project had several problems - no showstoppers, but lots of warts. I was griping about the still open bugs and continuously asking why on earth we were pushing out something that, in my estimation, did not seem ready for primetime nor would I want my name associated with it in its current state. I was so adamantly opposed to finishing the release, albeit internally as I certainly was not going to publicly stand in front of a moving locomotive to try and stop it, that it put me in a very negative and unproductive mood. In the midst of my griping to my fellow QA guru, he enlightened me to another train of thought - what are those business stakeholders thinking? How are the business stakeholders managing the risks associated with releasing software.
In short here is what I learned from that conversation - it is not up to me in the role of an engineer of an organization that finds itself in a rapid business climate to worry about the risks associated with releasing software in a certain state. My job is simply to make sure that software is releasable given the business' definition of what is releasable, and to improve it in the future in such ways the business sees fit. Building on that concept, it is even more important that it is not my job as an engineer to assess the risk of releasing a piece of software to the public as I, and other engineers are (typically) unqualified to do so. If it were left to (perfectionist) engineers, software would never be released as we would be trying to tweak and work on it until it is just right. But what is gained in quality will be lost by not actually having the software being used by its user base. Software is quite useless unless it is actually being used by someone. Software has to be released at some point to deliver needed features to users in the timely fashion that the business expects - and they are the ones who live with the possibility of whether the realized risks of bugs making it out into the wild outweigh or are dwarfed by the benefit of delivering new features to the client base.
The open-source mantra for such a concept is "release early, release often". Ever since the point in which I had that conversation with my QA guy, I have personally become considerably less uptight regarding releasing buggy software - and as a result I feel more comfortable working in this fast paced climate of frequent releases. Releasing imperfect software is just the nature of our lives. Our strive for creating something and moving it as close to perfection as we humanely can under realistic constraints is still the impetus driving us as software engineers - that will never be taken away regardless of how soon or how unready our released product is when others see it.
New Location
Subscribe to:
Post Comments (Atom)
5 comments:
Well said Whaley! Another saying which always hit home for me is "Development would be great if we didn't have users"
Good post. But as another developer with perfectionist tendencies I think there is another - perhaps more important - reason for releasing imperfect software. It is that software is almost always imperfect in some way - if only because users don't really know what they want.
... So if software is always imperfect - it makes sense to release early and get feedback to use in prioritizing task lists.
Vineet above has a good point :)
Our responsibility as developers is to raise our concerns to business. If you have a bug that you deem critical, let business know, and they will make a decision based on your input. In occasions they may be making the wrong decision because they don't have enough information, and it is our responsibility to provide it!
http://www.codeinstructions.com
Nicely written Whaley! Software is like college - there's always more you could do, but at some point you just have to graduate.
Thats a great post with some good points.
I'm currently completing a project (Windows mobile based field service solution) which I've managed the outsourced development on, spec'd, tested and trained and rolled out - and I'm a developer to boot. It's been unbelievably frustrating working with an external developer who, while good at the code he outputs, is careless by nature and doesn't understand many of the key concepts underpinning the code he outputs, which invariably causes bugs in the codebase.
Its been extremely uncomfortable, yet enlightening, attempting to strike that balance between "good enough" and "too buggy"; we reached a point at which I deemed it acceptable to release, then yet more bugs appeared in the field. Worse still, we were mis-sold the provisioning software that sits on each device to allow us to upgrade in the field - it will upgrade the software, but wipe out everything else installed on the device!
Now we have the source code I have the even less unenviable position of attempting to figure out where the bugs are in the code...
Post a Comment