Robert Carr is vice president of software for GO Corp., 139 Townsend St., San Francisco, CA 94107. He is the creator of Framework II and former chief scientist at Ashton-Tate.
How do bad software products come about? The reasons vary, but one of the most common faults is when programmers design the product "for themselves," forgetting product's real users. The key to avoiding this common pitfall is to realize that programming is ultimately for the use--the consumer of the software. You must view the process of developing software as a user-driven, software development cycle.
Software development is much more than programming and debugging; it's an overall life cy le of delivering software products to users. So central is the relationship between the user and the software product that the overall process should be called software delivery, not software development, emphasizing the delivery aspect as the clear goal.
The cycle of software delivery can be broken up into several phases, each with its own axioms. This article lays out eight such phases and their dictums. From the viewpoint of user-driven development, each phase offers a special contribution to the goal of successfully delivering software that makes your users rave about, demand more of, and pay for your software (and ultimately your salary). Although the eight phases are listed here in their natural order, in reality they often overlap; ideally, there is quite a bit of iteration and looping.
A last prefatory comment--although I refer to project teams, all these comments apply equally to the solo implementation effort.
Just as journalists and writers for decades have offered the sage advice to "know your audience," so should developers know the users of their products.
How can you find your users, so as to know them? Some developers are hired directly (say, as contract programmers or through corporate MIS departments) by their users or users' organizations that will use their products; these developers are fortunate--they know exactly where to find their users. Other developers in some sense develop for "markets" of unknown users; they must find a representative sample of potential users.
Once you've found your users, do something simple with them: talk to them yourself. Talk to them extensively, and do it before designing your product. If you have the sometimes mixed blessing of having a formal marketing department coming between you and your market/users, insist on accompanying or by-passing the product-marketing people to talk directly to users.
Much useful information can only be gained by direct contact with users. Software that makes users happy is hard to deliver on time and within costs and can only be created when design decisions are made with the most accurate projection of the users' reactions as is possible.
Although this may sound surprisingly simple, talking with users yields tremendous benefits when compared with the costs of presenting your users with formal marketing surveys or detailed product mock-ups.
Discuss the proposed software with them. Have they used similar packages in the past? What did they like and dislike about them? What are their hardware and software environment requirements? When would they ideally like the software by; when do they absolutely need it by? Or, if you're developing for the consumer market, what marketing windows do you have?--for example, when do you have to deliver in order to beat competitors to market?
One of the most powerful tools you have for meeting a targeted ship date is your ability to adjust the functionality and scope of your first version to fit the time available. Early, extensive user dialogue provides you with a gestalt feel for your market so you can make design trade-offs intelligently.
Craftsmen need sharp tools. Happily, because personal computers represent the first mass market ever for programmer tools, they're beginning to host the best programming tools ever. Unless you are in the business of selling tools, avoid building them yourself unless absolutely necessary--your job is building the product for the users, not tools for yourself. It's likely these days that someone else has already built the tool you need and is willing to sell you a copy for a few hundred dollars. Buy it and profit.
As with tools, so with building blocks. Seek to partition your architecture such that as many pieces as possible can be subject to the "buy vs. build" decision. Strive to prejudice yourself toward buying. And even when the final version shouldn't be shipped with a preexisting building block, consider using it in the early phases of your project so as to get the overall system running as early as possible. This is a vital technique, supporting the evolutionary-development technique discussed later.
Now that you understand the needs of your users, don't rush into programming; instead, spend adequate time designing an architecture that meets all major product requirements. Including user interface and performance. Go this far, but by all means do not go too far and extend this design phase until all aspects are finely designed to the smallest details!
Your preliminary design should give you a good handle on key algorithms, data structures, user-interface metaphors, major menus and their rough contents, the number and role of the internal modules, and the interfaces between key architectural layers.
At this point do not continue through detailed design of all prompts and strings, all menus and commands, all dialog boxes, all module interfaces, or writing of the entire program in pseudocode. Although you will need to do many of these things in the course of the project, by deferring detail you gain flexibility to change the product based on what you learn as you build it.
Although much of software engineering research and theory stems from the requirements of large military and aerospace software projects, we in the PC business need to be wary of applying these techniques to our work. What's necessary to produce satellite-control software at a large company is not necessarily the appropriate software development paradigm for us. And nowhere is this more true than in the need to avoid committing the complete design to paper before ever beginning to build.
Now is the time to perform selected tests, especially to highlight major performance issues--run a test to prove your design is sufficiently efficient. If, for example, you wonder if your windowing environment can paint characters fast enough, then write a test program now. If it doesn't, you know you have to redesign your display algorithms to minimize character painting.
The reason behind spending adequate time on design is to put your best efforts into avoiding major surprises or gotchas in the overall design of the product; these are the most costly to rectify. Even with your best efforts, it's likely there will be a couple of medium-size changes of direction/design that only become apparent in mid-course.
The most underutilized resources on most development projects are the programmers themselves! Often they are not allowed to discuss their own ideas with users or marketeers. Often they are pigeonholed into their one area and aren't even allowed to contribute to areas outside their own.
Ask discipline, professional work habits, and friendly interpersonal skills of your development team, and couch design and planning sessions in a consensus atmosphere that invites the best from everyone. Your team will then take the project closer to perfection than you guessed was possible. Emphasize the word team: what the team should value and aim for is what they can do together, not what any of them achieves individually.
A team-oriented consensus style is in strong contrast to concepts such as chief-programmer-based teams, for example, in which team members exist merely to make the guru chief programmer more efficient, implementing the designs that spring from his head. A benefit of inviting more contributions from team members is that their professional skills will develop more rapidly.
Once you have a clear understanding of your users needs and your product design, you're ready to begin programming. It's key now to adapt an evolutionary implementation method that provides you with the flexibility to make changes as you learn from the growing product.
Some day there may be CASE tools that allow an entire product to be changed with ease, but for now the best way to obtain flexibility is to build from the outside in: begin building from the user interface inward and from your low-level building blocks upward. It's the middle levels of most software products that consume your implementation effort and are the hardest to change. For it is at these levels that functionality and behavior tend to be hard-wired into the architecture.
Low-level building blocks tend, on the other hand, to be understandable and flexible no matter what the flow and functionality of the higher levels. At the user-interface level, use scaffolding and other temporary crutches to get your user interface running. By doing so users can interact with the actual product itself, providing valuable polish and validation to your design.
If necessary you can prototype the user interface using prototyping tools such as Dan Bricklin's Demo program. Strive, however, to avoid using such tools for extensive mock-ups when you could spend your time developing the real code (with a little throwaway scaffolding).
If ease of learning is an important goal of your project, now is the time to sit a few users down and have them try to learn the system. Watch them yourself and have your programmers do the same (videotaping is a good method here). If three out of four subjects stumble at the same point, it's likely that area needs redesign. Such user testing can be both cheap and easy to perform. (If your market includes computer novices, for example, you can use relatives and friends as test subjects.)
A long-term benefit of having programmers and program designers talk with users and view user testing is that over time the programmers sharpen their "user empathy" skills. Over the course of a couple of projects, the programmers will develop user empathy--the ability to anticipate, during the design phase, many user problems your team will begin to get a reputation for being sharp user-interface designers.
Many programmers resist changes to their initial designs suggested by the marketing department or remote designers. But programmers who experience first-hand other humans having real difficulties tend to respond empathetically and are more motivated to iterate and perfect and polish the overall product for these users--all because their users are real to them.
It sounds obvious, but a far too common sin is not shipping the first version soon enough. In fact, some teams never ship "Version 1" but change and hack and perfect the product so long that they ship what can only be called Version 2.
Although sometimes justified by changing market conditions, waiting so long is usually a mistake. By shipping late you may miss a key market window or make your customers unhappy because they had to make do. If you'd shipped when you had a reasonable first version together, you may have released the product before any competitors did.
Support your product once it's shipping. Innovative products in particular need repeated explanation and selling from their designers. Ideally, your talks with users before ever building the product gave you a warm-up on explaining its special benefits.
Despite your fervor in user testing and talking to users, there's no better way to get terrific feedback and guidance on evolving your product than shipping your product and then listening to the market.
Listen to your market by talking to the actual users of your product. Try to find a representative cross-sample of 15 to 25 users who you can talk to in the months after shipping. Question both beginning and advanced users of your product to get their reactions, but be sure to interrogate them again after a few months, when they've had time to plumb all the depths of your product.
Avoid the common mistake of releasing your software too often. Adequate testing and quality assurance at the end of a development project is expensive and often consumes four months. If you release a new version every ten months, you're testing four months for every six of developing. Furthermore, you have hardly any time to incorporate the expert users' feedback from your previous version. It's much better to adopt a 15-18-month cycle of releases, in which you have a full year or so of development for each testing phase. By adopting a discipline of following efficiently spaced releases, you can pull clearly ahead of your competition in features and functionality in just a couple of release cycles.
The software delivery cycle is ideally one that loops repeatedly: Each of the eight phases is applied to every major product release, although some, such as selecting tools and building blocks, are obviously much abbreviated on later releases.
Developing for users is not easy. But it provides a methodology that helps you avoid costly errors that are surprisingly common: developing products that nobody wants; or that nobody can learn or use; or that don't meet enough user needs to make them pay money, which is after all what makes us professional developers.