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

News Briefs: July 15, 2008 Enea is named to the board of CP-TA, Teradata introduces a new version of its data warehousing tool and SOA Software upgraded its Repository Manager to accommodate its Policy Manager software.

News Briefs: July 1, 2008 Cynergy's relocation triples the size of its headquarters, Microsoft releases version 1 of its Open XML SDK, NelsonHall predicts increased outsourcing, and AccuRev and Rally team up on agile CRM.

Process, Best Practices Are Best Defense Education and training of software developers, as well as creating and sharing best practices for improving quality, are among recommendations...

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST