Interesting article indeed. Thanks for the link. Since I've been
involved with developing and shipping software since the mid-80's here's
my 2 cent take on it all.
Regarding shipping bug-free code: Things have changed radically!
It used to be, we would make every known effort to not ship a product
with known bugs. But, there are 3 factors which have changed my
perspective on this:
1) The overall complexity of software and perceived 'bugginess' by the user.
I really think MS is most to blame for this. People now 'expect' their
software to not work correctly, because after all, their OS is reported
unsecure and buggy every day in the media. When in fact, I believe there
are less crashes and XP is more robust, the perception still exists
'it's not quality software.' The simple fact is, when MS can't build a
secure product, how can our clients expect us to?
Also, as more developers are involved and more feature creep and
customer expectation of 'the new and advanced,' it just goes to reason
the software will not be as robust.
RR is a good case in point. As many of us 'old timers' know, MC has a
very primitive, yet 'bug free' IDE, which Scott Raney (father of the
transcript engine) was adamant regarding NEVER shipping a release
version of the engine or IDE with a confirmed bug.
Course, RR's IDE is much more capable, and much more complex, and
therefore much more difficult to make 'bug-free.' If RR adopted Raney's
approach, they'd never ship.
2) The understanding that budgets and schedules have for the most part
gotten smaller.
Back 'in the day', we saw huge budgets for websites, multimedia
projects, not to mention app development. But, with tools like RR, Real
Basic, Java, .NET-- things have changed. Now, IT departments and
marketing/sales managers are more savvy and understand better the real
trade offs to get 90% there vs 100%, and often opt for the former.
3) *(the most important)* the ability (and perception) to update a
customers product in realtime over the Internet.
People are connected to the net and used to updating their programs,
OS'es, etc over the net. In fact, products frequently ship on-time but
get a 'dot release' improvement soon thereafter. I really like this
model, as it enables Altuit to rapidly respond to bug reports, feature
requests, etc.. In fact, just last night, a customer asked for a rework
of an existing feature, and I was able to do it, and post it, all within
2 hours. From there on, all customers immediately get an update (via
MagicCarpet AutoUpdate architecture) the next time they launch. Of
course, imperative in this scheme is the ability to 'roll-back' versions
as well.
Frankly, I believe many software products would benefit from a
'subscription online auto-update' model. This would provide a deterrent
to pirates, while maintaining contact with customers. It would also
force developers to pay attention to quality and not just 'feature bloat.'
-Chipp
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
