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


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

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