LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

First, or Best, to Market?


By Allen Holub
September 15, 2004 — 
How important is the notion of "first to market?" I had intended, in this column, to review VisiComp's RetroVue debugger, but unfortunately, the installed (as compared to demo'd) version was disappointing. RetroVue is a wonderful idea: a debugger that keeps a history of your execution so that you can definitively answer the question: "How did that happen?" But the shipped product simply is not good enough to be thoroughly tested and reviewed; my guess is that they were so interested in being first to market, they released too early, rendering a potentially great product disappointing. Rather than discuss RetroVue, then, let's talk about the first-to-market issue.

Putting things into perspective: Of the billion-dollar products that are endemic on today's PCs (spreadsheets, databases, word processors and operating systems), can you name any product leaders in these categories who were first to market? The first-to-market PC-based products in these categories were VisiCalc, DBASE and WordStar, and CP/M. None of these products (or the companies that created them) exist today. Being first to market often does nothing but prepare the marketplace to accept the second-to-market products. Nonetheless, the gospel of first to market pushes people to release too early.

But don't you have to establish a "beach head?" Can't you fix the problems in version 2? People subjected to a bad version 1 won't try version 2. The competition won't be sitting on its hands waiting for you to get your act together, after all. Your potential customers, remembering their experience, will try the competition first, and people will stay with the first solid product they find.

So, "first to market" doesn't matter. "Successful in the marketplace" does. And it can't hurt to get to market as quickly as possible. So how do you quickly develop a successful product? I'll answer that question with another: What does a successful version 1.0 release look like?

First and foremost, no obvious bugs. Bugs are endless, but your product will simply fail if your schedule is more important than the bug count. The best way to deal with this problem is continuous testing. I'm a strong believer of Test-Driven Development (TDD), which advocates writing tests before you write the code you're testing. TDD alone cut my development time by at least half. Without automated regression testing in place, it's simply not possible to refactor your code (improve it without changing functionality). There are lots of tools to help in testing. Erich Gamma's JUnit (www.junit.org) and its clones are everywhere. Find information about TDD atwww.agiledata.org/essays/tdd.htmlandwww.testdriven.com.

What better way to test than to give the real (though incomplete) program to real users, and have them use it? Continuous release of your software to a small user community gets you the feedback you need to produce a truly great product. It also measurably reduces bug counts and improves productivity. Regular releases aren't helpful if you can't keep track of the bugs, however. (Interestingly, the very act of tracking bugs reduces the initial bug count. Mozilla's Bugzilla system (www.bugzilla.org) is a free bug tracker that's just as good as the expensive ones.

The most bug-free program in the world is useless if you can't figure out how to use it. Bad documentation, often tacked on as an afterthought, is usually a recap of what you can see in front of you on the screen. Useful documentation first identifies the problems that your users are trying to solve, then shows them how to solve those problems by walking through a set of common tasks.

This philosophy describes the first two steps of the OO Design process: problem definition and use-case analysis. Upfront design gives you the user documentation before you write the code! By building your UI around the use cases-the user tasks-your program is more intuitive and needs less documentation (see Larry Constantine and Lucy Lockwood's "Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design"). More important, working with real end users to define your use cases guarantees software that's truly useful.

Upfront design not only gives you good docs, but also cuts development time. You don't have to design the entire program before writing any code, but you can't code even a small piece of the program if you haven't designed that piece first. The agile methodologies all design on the fly as the program develops, but that doesn't mean that the agile folks don't do design. They design continuously.

None of what I've just written is earth-shattering. We've all known how we "should" build software; we just don't do it. It's about time everyone realized that building quality code gets truly useful software to market faster with fewer bugs, and that's a recipe for success.


Share this link: http://www.sdtimes.com/link/28155
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading