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.
Mamddoh 
Leave a comment