There is trend that is becoming popular in software development these days. A lot of companies adopted the agile development model, with one of its slogans ‘release early, release often’. While there are many wildly successful products released using this methodology, this idea is often applied incorrectly, leading to unsuccessful software (as defined by ). The point of this article is to show how and why this process can lead to software failure, especially of commercial software, whereas the software is a final product that the end user pays for.
Good old days and how its changed
When you think of a tangible product, say, your favourite coffee table or a new blockbuster movie, they all have one attribute in common – they are finished products. Once you purchased one of them, thats it. The product is not going to be upgraded or get new features – it is not going to be maintained (and if the design of the coffee table is updated or a DVD with extras is released, it’s sold as a new product). Software is different in that regard – it can be updated, patched up and so forth.
In the old days, most software got distributed like any other tangible good – on CDs. Any updates and fixes would usually go into the next release. Now, when most software is distributed through the internet, the mindset has changed. Sending out updates is quick and easy. Fixing small annoyances or critical bugs, adding extra features – there is nothing that can’t be done after release, if needed.
Every company wants to be the market leader. There are many possible ways to achieve that, but they usually all boil down to:
a) Have the best product
b) Be the first on the market (find one or be innovative and create a market for some product)
The first one often spans from the second one. Ideally, by being the first on the market, you can capture the majority of the userbase (all of it, if nothing even remotely similar exists). Users, in turn, provide you feedback on your product, on how to make it better suit their needs. If suggestions are followed through, users will not have much incentive to switch to a competitors product and you’ll be able to dive like Scrooge McDuck.
So, if you want to be the first person on the market, it is often better to release your product as early as possible, before any competing product is created. Even in existing markets, when some interesting development occurs in the field, it if often beneficial to be the first company to implement that feature. This approach worked out quite well for a lot of companies, for example, almost all Google products are released in beta stages and they quickly gain popularity as bugs are swiftly fixed and updates released. Another great example of releasing before the product is completely polished is twitter: there was nothing quite like it on the market, so, despite its shortcomings (fail whale anyone?) still gained traction and no competitors come even remotely close to taking market share from twitter.
It seems that releasing a product before it’s perfect is the perfect solution, as users are becoming more lenient towards execution if the software product is innovative enough.
So, what could go wrong?
Trouble in paradise
The idea of updating post release is often taken to the extreme and we getting products that are just not ready for the market. This trend is currently most apparent in video game industry. Whats worse, is that these software prototypes are sold to the end user at full price, with promises of providing a complete product at some point in the future.
One such example is Steam Early Access programme, whereby you can purchase unfinished games (usually by indie developers / small companies) and help the developer test them. One can sugarcoat it as much as he likes, but a customer is essentially paying to do a job that people are usually paid to do. This is a gray area in terms of software failure. On one hand, software is buggy and it does not satisfy quality requirements of the intended end product. On the other hand, people who purchase early access know that they are getting an unfinished product and should expect bugs and crashes.
Lets assume for a moment that users really liked the previous works of the company and want to support it in its next software endeavour. Another issue arises – feature creep. The software is in this almost-released state, the number of stakeholders, who invested their time and money into the product, increases. Each stakeholder wants to pull the project towards slightly different direction. Whereas previously a developer could decide which features to leave and which to cut from the final release, now the line is blurred. It is now impossible to please everyone who already bought the product. Another thing to consider, is that users can be terrible at giving feedback, and generally don’t know what they want until they are presented with a solution. In this case it is possible, that listening to solutions from the small group of uses can lead to making software that is undesirable to the majority of your target audience. In either case, this leads to a software failure condition where the software does not satisfy users needs in terms of scope.
Lastly, the issue of development time arises. Quite often the periods in which the software stays in a ‘beta’ stage can last for months or even years, with no clear deadline for the finished product defined. Better, finished products (maybe not as feature rich, but very stable and usable) could have appeared on the market by then. When such competitor product appears, the initial software can be considered a failure in regards to being delivered in time.
To release or not to release
In general, releasing early to get feedback is beneficial to a software product. It just has to be done right. Feedback from users should be a supplement to your software development lifecycle and not be the only driving force behind it. Otherwise the aims of the project will expand indefinitely and never be achieved. Early access should also not be sold to users at the full price of the finished product. Testing your software is a favour that the users provide you and not the privilege they have to earn. Finally, set a release date and release your software then, don’t drag the beta-stage forever.
 The Art of Agile Development http://books.google.co.uk/books?id=g_ji7cRb–UC&lpg=PA208&ots=vmQwDuYF3y&pg=PA208#v=onepage&q&f=false
 SAPM, Success http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/6
 First-Mover Advantage http://www.pearsoned.co.uk/Bookshop/article.asp?item=312
 The Beta Principle: Skip Perfection & Launch Early http://99u.com/articles/6313/the-beta-principle-skip-perfection-launch-early