Welcome to the first installment of our new column on developing software applications. I know a lot of you have secret aspirations to write a software program, but you don’t know where to begin. The documentation for your development tool of choice probably has plenty of information about what you can do, but not much information about when, why, or how you should apply that knowledge.
In this column, I’ll introduce you to the basic software engineering principles you need to build applications that work right the first time. Even professional developers recognize the difficulty of achieving that claim, but then again, many professional developers don’t necessarily follow good software engineering principles!
Over the years, I’ve worked on a lot of applications and used a lot of tools that are supposed to help you design and build software applications. The problem with most of these tools is that they become an end in themselves. The development team becomes mired in the jargon and idiosyncrasies of the tool and loses site of the real goal: to quickly build reliable and maintainable software that is easy to use. Also, you usually have to buy into the tool vendor’s idea of how an application should work, which is a limitation that doesn’t make sense in a world where software development environments evolve as rapidly as they do.
Since I’ve run the show at my own software development company, I’ve returned to using a few principles and techniques that are simple, inexpensive, and fast. I’ll be sharing those principles and techniques with you in this and future articles in this column.
Where to Start
So, how do you get started on a software project? Most of us are taught that the best place to start is at the beginning. That saying is usually spoken with a smirk because it’s self evident, right? Wrong! Actually, the best place to start is at the end. You have to know where you are going before you begin the journey, unless you don’t mind a lot of backtracking. If you don’t plan ahead, your software project will wander aimlessly too.
Define Goals
Your first order of business is to define your goals. Your goals should succinctly state the purpose of the project. Think about what problems you are trying to solve and what questions you are trying to answer. Goals should be based on needs.
Goals are always about what comes out of the system, not what goes into it. There is no point in collecting information if you aren’t going to do something with it.
Establish a Mission
I recommend that you distill your goals down to a single mission statement for your project. You do this for two reasons: first, so you can quickly describe your project to others, and second, so you can prioritize your development tasks.
When someone asks you what your program does, you should be ready with a one or two sentence response that sums it up. That response is a good candidate for your mission statement.
Later, during project design and development, you should focus primarily on the features that most closely relate to your mission statement. The mission statement helps you avoid being sidetracked by "feature creep," which is the tendency for projects to acquire "nice to have" enhancements during development.
In fact, any enhancement that is introduced with the phrase "wouldn’t it be nice if" should probably be postponed to version 2. Start with the essentials, or you will never finish version 1.
Example
To give you an example of what I’m talking about, let’s say you are planning a program that keeps track of the books you’ve read. Why do you want this program? Perhaps you check a lot of books out of the library, or you do a lot of used book trading. You want to make sure you get more books by the authors you like, and avoid the authors you don’t. You want to keep track of your favorite book series so you can easily spot others in those series. You want to make sure you don’t accidentally get a book you’ve already read. Goals like these define the purpose for your program and give you something to work toward as you start the design process.
Your mission statement for this project might be to "organize information about the books you’ve read so you can easily identify others you might like to read." This project will help you make the most of your journeys to the bookstore and the library.
Say What
Note that your goals at this point are pretty vague. You’ve only determined what you are going to do, not necessarily how you will accomplish it. Of course, it doesn’t do you much good to come up with goals that you are not capable of reaching. As your development experience grows, you will learn how to differentiate between goals that are easy, difficult, and impossible. Also, experience will help you move more of your ideas from the impossible category to the difficult category. As someone once said, "the impossible just takes more time."
