Writing Software: 6 Key Questions to Ask When Initiating a New Project
Software developers are a unique breed. We love to think in abstract terms. Many of us are more comfortable communicating in Java than in English. It’s a sign of a truly advanced civilization that software developers have been put to meaningful work rather than sequestered from the rest of society.
If you read my previous post, you know that I am passionate about writing software on a human scale. This means writing software that serves the user, rather than forcing the user to conform to the software. There are lots of hurdles that developers must navigate to achieve this ideal. The first is probably obvious: how to get started.
Let’s follow Maria Von Trapp’s advice in “The Sound of Music” and start at the very beginning. Before we write a single line of code, we need to have clear answers to some very basic questions. A good way to approach those basic questions is to use the classic “Five W’s” that we all learned in school: Who, What, Where, Why, When and How. Here is a quick primer on how this applies to initiating software projects:
WHAT must the software do?
These are the “Must Haves.” Come up with a list of 5 – 10 bullet points that enumerate what the software must do to be successful. If the list gets longer than this, the project should probably be broken into smaller iterations.
WHY is it important?
These are the “Must NOT Haves.” Summarize 3 – 5 problems (as reported by the users) that will be addressed by this software. Are there things they can’t do that they need to accomplish? Are there things that are harder than they should be? Are their customers complaining about issues or missing functionality?
WHO is required to be successful?
- Developers and other technical experts
- Project managers
- Business domain experts
- End users and customers
WHERE will the project work be done?
Do not make assumptions about the geographic location of any resources (human or technical). Cultural differences abound across environments, organizations and people on the development and implementation side. Assumptions about any of these differences can often make or break a project.
WHEN will the software be ready for the user?
This will likely be a moving target as information changes. Start somewhere with your best guess. It’s much easier to alter project timelines as you go than to shoot for vague or unspecified targets.
HOW will all these other questions and answers be integrated?
This is the last question you should ask yourself. As you review the Five W’s, you should have a clear enough view of the significant details that you can say with confidence, “This is how we should approach this problem.”
Over the next few posts, I’ll unpack these a bit and discuss how we can use basic journalistic techniques to learn what we need to know to get started. In the meantime, what questions would you add to this list? How is my approach similar (or not) to your approach?