To Release With or Without Bugs?


Archive: March 6th, 2013

[Editorial] I've been sitting here pondering an increasingly relevant topic regarding flight simulation add-ons. That topic being, is it okay to release products with known bugs or deficiencies? My initial reaction is no, absolutely not! However, the more I think about the topic the more I am conflicted. Read more for my rant/editorial.

The idea of releasing something that has outstanding bugs is by definition releasing something that is flawed.  However, the word flawed may be somewhat dramatic in relation to this topic. The word implies that something is mostly unusable or at least very poorly put together. This of course is not always the case. Several developers have openly released products with outstanding bugs, some of which have been extremely usable and just as importantly, been patched at a later date. Alternatively, some have released products that were hardly usable without ever truly correcting the outstanding deficiencies.

So, what are the advantages of releasing a product with known bugs from the perspective of the developer? Firstly, the product hits the market sooner and subsequently, starts to generate revenue. Next, the release puts both the product and developer in the spotlight, even if for a short while. Lastly, it allows the developer to pursue another project and another potential income source. Clearly, there are significant advantages to releasing products with bugs. 

These advantages leave me with one question… when does the developer find time to address the issues that weren't manageable the first time around? If they weren't easily correctable before release, surely they won't be after release. All the above noted advantages lead the developer in one direction, to pursue future endeavors and income streams. Now let’s think about this, it’s almost completely illogical. First, release a product, then get paid for the product, and finally, spend significant amounts of time after being paid fixing bugs that weren't easily fixable before release forgoing the opportunity to focus on the next project. Where’s the motivation for that? I don’t get it?

Let’s not forget, once released new bugs will likely be discovered and there will be a further expectation to fix those as well. 

So has this strategy been done successfully, absolutely! Some of the most respected and well known developers have done this and done it well. I see very little harm in developers pursuing this business practice given certain conditions.

Firstly, ensure the product is completely usable as advertised. This means, if you are releasing a complex “tubeliner”, the FMS better integrate correctly. If you are releasing airport scenery, the runway better not cause the aircraft to crash. Any deficiencies must not impede the user’s ability to properly use and enjoy the product.

Next, warn potential customers not only that there are bugs but exactly what those bugs are. Developers should be very transparent in this regard.

Lastly, the developer must actually correct the preexisting bugs, no matter how small. This means the developer must fully accept there will be a significant but mandatory unpaid time commitment after release. 
If developers are willing to accept these terms, release away!

What did we learn from this rant, likely nothing - just thinking out loud.

-Mark Hrycenko