I would much prefer that Akai take the time to do rigorous testing to insure that absolute stability of the next release, rather than yielding pressure from impatient customers (and all of us are that at one time or another). In firmware development, there is always a lot of pressure to get the product out the door as quickly as possible.
When a project is started, a schedule is set, as well as the estimated development costs. Somewhere around halfway through the schedule, we start to see the various problems that need to be solved, that were not accounted for in the initial planning. This ALWAYS happens because you can't predict every possible problem that could be encountered. The more complex a product is, the greater the chances and impact of this happening. The MPC X/Live is just such a complex product.
However, the schedule is usually not adjusted to account for these problems. What happens instead is that the release date is publicized, and everybody then needs to work lots of evenings and weekends to try to meet that date. If any engineers from other projects can be freed up, they will be thrown into this project. Then, you have the "Mythical Man Month" situation (a book that used to be required reading in an engineering curriculum) in which the number of communication paths among development team members and management increases dramatically, making the project that much more complex and prone to error.
The human body is what it is, and after some number of hours of intense focus on a problem, or even just writing tons of code, we begin to make mistakes that then have to be corrected the next day, if they are discovered at all. This makes for decreased overall efficiency. After a certain point, the efforts to meet the schedule become self-defeating.
A very accurate rule of thumb is that the earlier a problem is discovered in the product's life cycle, the easier and less expensive it is to fix. It is much easier to fix a problem that shows up in final test than it is once the product is in the field. It is much easier to fix a problem BEFORE it goes into test, than it is in test when all the code has been piled on and there are far more paths to go wrong.
This stuff happens on nearly every project of any size and complexity level, but we continue to do things the same way all the time, rather than allowing for more time to get the project done in the initial estimates.
Finally, the schedule "slips" and that must be announced. Since expectations on the part of the sales force and the expecting consumers of the product had already been set, this causes a high level of frustration and potentially, lost sales as folks look elsewhere for a similar product, if there is one available.
Testing comes at the end of the development cycle, and it is the first part of the schedule to get squeezed as development takes longer than expected. Therefore, the product often is not tested thoroughly as a result of reduced test time, and then you see all the complaints about bugs in the forums.
In my opinion, as a result of having lived through many projects which all followed this path, it seems that it would be much better for all concerned, to provide a more accurate schedule in the beginning, padding it for the unexpected, that then be flexible enough to insure proper testing at the end. Instead, what often happens is that the engineers put together their time and cost estimate, and then management decides that the schedule is too long/expensive and must be shortened and some corners cut.
There is always the big fear that somebody else is creating a similar product and will get to market first. The reality that nobody seems to consider is that a product of a given size and complexity will take a certain amount of time and no company can magically make that shorter without encountering the problems I describe here. The only way to get to market first with a solid product is to have started before the competition. So everybody plays this game and the consumers of the product continue to complain.
One thing I have seen happen is that a product with really deep features, will have its test time spent on the features that the company thinks most people will use, leaving the more obscure features to be tested and fixed in subsequent releases, which rarely happens since every release will add still more features that need testing.
So what we end up with is that we buy the initial release of a product, and hope that the company continues to develop it for a few years to at least get to the point where a reasonable WORKING feature set is achieved before the company goes on to the next shiny new thing. Sometimes, we are lucky and this does in fact, happen. Other times, the company decides to abandon the product for something they feel has more potential for revenue. Let's hope Akai decides the MPC X/Live generate enough revenue to have a useful life cycle worth developing to completion (whatever that may be).
I have also seen products "run off the rails" because the company really tries hard to take all the user complaints and suggestions, and address them all. This can get to be too much because there is one development team of fixed size, but any number of customers and potential customers, all posting and complaining. The net result can be that the product never becomes stable because every release adds lots of new, and largely untested, goodies in a vain attempt to appease the customer base.
As a consumer, I have had only one product that has never had, nor needed, a firmware upgrade after its release. That product is my Roland V-Grand digital piano. I have never encountered ANY problem with it. It just works. Of course, it is a very expensive product, Roland's flagship digital piano, which they put 10 years of development into before releasing it. Most of the typical products we have would not take 10 years, but the V-Grand was the first all modelled digital piano that truly attempts to recreate an immersive experience of playing a real grand piano, with all new technology developed to make that happen.
Tony
implies more features, vs. simple bug fixes. Fingers crossed.
