Coder to Developer
By Mike Gunderloy
John Wiley & Sons ISBN: 0-7821-4327-X
Chapter One Planning Your Project
How does one design an electric motor? Would you attach a bathtub to it, simply because one was available? Would a bouquet of flowers help? A heap of rocks?
-Professor Bernardo de la Paz, quoted in The Moon Is a Harsh Mistress, by Robert A. Heinlein
So there you are with your shiny new IDE and your coding skills and a vague idea of what it is that you want to produce. The temptation can be almost overwhelming to dive right in and start typing.
Don't do it. Even the smallest of projects benefits from at least a little bit of planning up front, and yours is no different. In this chapter, I'll discuss some of the basic planning steps, including requirements management and choosing a methodology, that you should consider before you write a single line of code.
Nailing Down a Feature Set
Before you write a single line of code, there's a simple yet difficult question that you must answer: What are you writing? You need to have more than a vague idea of the end product before you can finish building an application. If you don't know what you're trying to produce, then you're not really writing an application; you're just noodling around with code. There's nothing wrong with that as a learning activity, but as a developer, you need to be more focused.
"What" is not the only question you should be asking about your application at this point. In fact, you should think about the same set of questions that a good newspaper reporter asks:
What are you writing?
When do you want to finish writing it?
Where do you expect it will be used?
Why are you writing this software?
How will you write the software?
I've found it useful to start the process of software development with some brainstorming activities. The goal of brainstorming is not to come up with all the answers, but to develop a set of ideas that you can reasonably expect will include the answers. In the context of focusing your software development, that means that you want to have a pretty good idea of the features of the finished product before you start building it. It's possible, even likely, that this list of features will change as you actually build the application. That's OK; for right now, you just want to have a clear direction, even if the ultimate destination changes later.
If you read the Introduction, you know that my sample application for this book is named Download Tracker, and that it has something to do with downloading software from the Internet. So far, Download Tracker is just a vague idea: I want to keep track of things I download from the Internet. To come up with an initial feature set, I'll develop an elevator pitch and a mind map.
The Elevator Pitch
The elevator pitch is an idea that was popularized during the peak of the dot-com era, when it seemed as if there were buckets of money out there to be had-and a lot of competition for having them. The scenario goes like this: You're on your way to a meeting with the venture capitalists on the 87th floor of the skyscraper. You've got your laptop loaded with PowerPoint slides, and collateral to hand out. Your 15-minute presentation is honed to a glittering edge.
Then, just as you step into the elevator in the building lobby, the senior partner from the VC firm steps in with you. "So, Bill," he says, "what have you got for us today?" Forget the 15-minute presentation. You've got a 30-second elevator ride to impress this guy and convince him to add zeroes to your bank balance. What do you say?
You're probably not going to get an eight-figure investment from someone who thinks your idea is fabulous, but coming up with an elevator pitch is still a very useful exercise. The important thing is not to create your elevator pitch quickly, but to be able to explain your software quickly. You might also think of this as coming up with "100 words or less" to explain your software.
Write a short statement describing what your software will do, and why, to help keep you on track.
If you're unsure whether a potential new feature should be added, ask yourself whether it fits in with the elevator pitch. If not, either the pitch needs to be modified or the feature should be discarded. When in doubt, discard the feature. Feature creep-the continuing addition of new functionality while you're still writing the code-is one of the biggest enemies that keep you from actually finishing a project.
Here are some things to think about when you're coming up with your elevator pitch:
Short is better than long. A long and rambling elevator pitch probably means you haven't really decided what you're building yet.
Functionality trumps technology. Potential customers care about what your software will do. They usually don't care how your software does it.
Solve a problem. If you can't explain what problem your application will solve, customers won't know why they should buy it.
Pitch the benefits, not yourself. Customers won't be buying you, your superior knowledge, or your development team (if you're lucky enough to be working with a team). They'll be buying the software.
Figure out what's important to your audience, and make sure you address that. Are the people buying your product most interested in cost, innovation, features, compatibility, or something else entirely?
With those points in mind, here's an elevator pitch for Download Tracker:
Download Tracker builds a personal catalog of all the software that you download from the Internet. You can add descriptions and keywords to identify each software package. Later on you can edit this information and add your own ratings. With Download Tracker, you'll never forget where you saved a program again, or lose track of the name of the file that installs your favorite freeware application. If you run a website, you can even use Download Tracker to automatically generate a list of your favorite downloads, complete with hyperlinks.
The Mind Map
The elevator pitch is a great tool for gaining focus on your application. You can print it out and nail it to the wall over your monitor to keep you motivated when you're chasing bugs at 3 a.m. and that last slice of pizza puts you into the heartburn zone. But after you've achieved that focus, you need to expand your view. This is the point where I'll typically start brainstorming a more detailed list of the things that the software will do.
There are a lot of ways to do this brainstorming, and choosing between them is largely a matter of personal preference. Some people like to use a text editor or a word processor and just type ideas, perhaps organizing them into an outline. Many developers are happy with a whiteboard for this purpose, although that leaves you with the problem of saving the whiteboard contents for later reference. If you have this problem, take a look at PolyVision's Whiteboard Photo (websterboards.com/products/wbp.html), though at $249 it may be too pricey if you're not a frequent whiteboard user.
The software prices I quote in this book are current in early 2004. Prices do change, though, so check at the relevant websites before making up your budget. I'm including prices so you know which tools are free, which are inexpensive, and which are potential budget-busters.
My own personal choice for freeform brainstorming is the mind map. Tony Buzan, who invented this form of diagram, describes a mind map as "a powerful graphic technique which provides a universal key to unlock the potential of the brain. It harnesses the full range of cortical skills-word, image, number, logic, rhythm, color, and spatial awareness-in a single, uniquely powerful manner." You can think of a mind map as a sort of two-dimensional outline; rather than organizing ideas into a linear list, you spread them around the page and connect them. Mind maps can also use icons, graphics, fonts, colors, hyperlinks, and other techniques to include information that's hard to put into words.
For general information on mind mapping, visit Tony Buzan's website at mind-map.com/.
There are several software packages out there to create mind maps, which is a good thing, because most developers don't have the graphic skills to create a nice one by hand. Table 1.1 lists some of the mind-mapping software available for Windows.
Figure 1.1 shows a mind map of features, ideas, and notes for Download Tracker. This mind map was created with MindManager X5 Pro. As you can see, I've got a fair number of things in mind for this product.
One of the best features of software-generated mind maps is that they're dynamic. It's easy to move branches around, add or delete text or images, and otherwise update mind maps. If you're using a mind map for brainstorming, consider updating it as your project proceeds to give you a continuously current snapshot of your ideas. If you do this, I suggest you archive a copy of the original version first. When the project is released, it's fun to look back and see how your ideas about it have changed and evolved.
Depending on the project, coming up with your initial feature set can ease into a formal process for handling requirements. One thing needs to be clear right up front, though: Not every software project needs a formal requirements process. In general, I've found that requirements management is more important when the requirements come from someone other than the software developer. If you're building software to implement your own vision, you can probably get by without anything more than a mind map or feature list to cover your product's requirements. But if you're building an application to handle data entry for an insurance office, you're probably not an expert in the problem domain (that is, in the details of the business of selling insurance). In that case, paying more formal attention to requirements can save you lots of grief down the road.
As a middle path, you might like to track your product's requirements with a bug-tracking tool. I'll talk more about this in Chapter 9, "Tracking and Squashing Bugs."
Broadly speaking, the requirements for a piece of software define what the software should do. But it helps to have a framework for classifying requirements. One useful framework comes from Karl Wiegers' book Software Requirements (Microsoft Press, 2003). Wiegers distinguishes four types of requirements in his taxonomy:
Business requirements High-level objectives of the organization or customer who requests the system.
User requirements User goals or tasks that the users must be able to perform with the product.
Functional requirements Software functionality that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.
System requirements Top-level requirements for a product containing multiple subsystems. Note that not all of the subsystems will be software!
This Year's Model
Developers tend to be a bit like magpies. When we see something new and bright, our instinctive reaction is to cart it back to our nests. "Ooooh, shiny!" could be the slogan on our coat of arms.
One place this is evident is in the way that fads sweep the development universe. For example, take peer-to-peer. For a while, it seemed as if everyone was building their software to be peer-to-peer enabled. "Our product will be the best peer-to-peer enabled fish scaler on the market" isn't a real elevator pitch, but it surely could have been. There are plenty of other technology fads that I'd put in this category, for example:
Now, certainly all of these are useful technologies for some things. But they clearly don't belong in every single product on the market. Particularly when you're a small shop, it's important to concentrate on adding real value, rather than simply buzzword compliance. Restraining yourself will also prevent you from wasting time learning a new technology, only to find that it's a dead end (anyone remember Data Reports from Visual Basic 6?).
Here's a tip: When you read an article about some hot new technology, resist the temptation to immediately add it to your code. Instead, write it down on a sticky note and stick it to your monitor. If your application really needs a distributed reflection-based plug-in API, it will still need it in the morning. If not, it's a lot easier to rip off the sticky note than to roll back the code changes.
Wiegers divides the process of working with these requirements into requirements development and requirements management. Requirements development further divides into a complex set of elicitation, analysis, specification, and validation activities, with feedback loops between them. After requirements development has teased out the requirements for a product, requirements management entails the process of coming to an agreement with the customer as to what the requirements are, and tracking the progress of the product to meet those requirements.
Requirements are rarely static. If you're building software for an external customer, make sure you and the customer agree on how the requirements can be amended, and decide up front who bears the burden of any additional costs.
Eliciting Requirements Checklist
If you're working with an external customer, this checklist will help you elicit the requirements for the software:
Talk to the actual end users of the software. Ask them what they expect the software to do.
Watch how the end users perform their job now. Make sure you understand how the software will change things.
Write a vision and scope document, explaining what's a part of the project and (equally important) what is not. Make sure the customer agrees with you.
Hold an informal group discussion with the users over lunch or a night out. People will speak up in a group of their peers even when they won't tell you things one on one.
Document the requirements you determine in plain English, and then check with the users to see if they make sense.
If you're replacing existing software, find out what's wrong with the current system. Your requirements will often boil down to fixing the problems.
Arrange the requirements in priority order and make sure the customer agrees on the priority.
At the end of the requirements elicitation process, you should know what the software will do. Just as important, the customer should have confidence that you understand their requirements.
Eliciting and Documenting Requirements
If you're writing software for yourself, eliciting requirements (often called needs assessment) is simply a matter of writing down what you think the software should do. If you're dealing with an external customer, the process can be much more complex. There's no alternative to getting the customer to tell you what the requirements are, but you have many ways to go about this. You might observe them at work, exchange frequent e-mails, or even convene a formal requirements workshop. For this book, I'm going to assume that you are your own customer, and hence, a formal requirements elicitation process is unnecessary. If you're working for an external customer, the sidebar "Eliciting Requirements Checklist" will help you get started, but you should also read Software Requirements or another book on the subject.
The issue of documenting requirements still remains. One useful tool for a formal requirements document is the use case. A use case describes one or more interactions between an external actor (which might be a person or another application) and your application. Here's a partial list of use cases for Document Tracker:
Publish Software List
Search for Software
Two or three words isn't much in the way of documentation, of course. To seriously employ use cases for requirements, you'll need a more formal document for each use case. Typical contents of a use case document include:
1. A unique identifier for the use case
2. The use case name
3. A short text description
Excerpted from Coder to Developer by Mike Gunderloy Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.