[OT] Determining shippability

[Chipp Walters]

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