Solving problems
In the past, people have asked me how I actually go about implementing solutions to the problems that I have been assigned. This stems largely from the fact that they seem to think I look like I am less stressed while I work on projects or because my solutions tend to work without nearly as many problems.
Since most of the people who make this inquiry are either other developers or programming students, the following is basically how I go about solving new software development problems, but I use variations of the methods for most non-trivial problems which I have to tackle. Please note that this article deals with concepts at a fairly high level for the sake of brevity and will not deal with billing whatsoever.
1) Meet with the clients.
I know that this seems obvious, but I’ve seen a lot of projects where a few sketchy details were just discussed over the phone or via email. Needless to say, I wasn’t impressed with the results (and the people commissioning the application usually weren’t either).
There are several reasons that you should actually sit down and meet with the clients who want to commission you. First is that you can find out not only what they say that they want/need but also what they really want/need (though this is often like pulling teeth). They may say that they want it to do everything including creating french fries in 26 shapes, but what they really need is something completely different. This helps reduce requirement changes later in the project, though changes are almost inevitable.
Second, it lets you see how they actually use the software they currently have as well as the processes they follow for doing their daily tasks. Things in their operating procedure that they take for granted may, in fact, be extremely important.
Third, it lets you get a feeling for whether they actually want the project to succeed. This may seem completely counterintuitive, but due to political in-fighting, some projects are set up expressly to fail in order to get back at or get rid of a rival in the company.
If you find yourself being solicited for such a program, you have a couple of choices. You can either back out gracefully or you can take on the project, knowing that it’s going to fail. I do not recommend the latter approach as it can cause you a great deal of headaches and may even be used to damage your reputation.
Meeting with the people who actually want and will be using the software should give you a list of requirements.
2) Sit down and think about the requirements.
After meeting with the customer(s), you should find that the requirements fall into roughly three fields:
If you are unsure where any of the requirements you have gathered fit into this model, ask the people who want the software. After all, they know how they want to use it better than you do.
However, take the advice with a grain of salt, because, in my experience, some managers think that every part of a program is vital and nothing can be cut even though they suddenly want you do finish it in half the time or on half the budget (some may even try this to get the program cheaper, thinking that once you’ve agreed to do the program, you’re locked into it no matter what they do to you).
3) Make a PLAN
Plans are like showers. Everyone needs one, and you don’t usually want to work with people who don’t have one. In the one case, the person without the shower tends to be a bit offensive and in the other, the product created without a plan tends to be.
It may seem like a lot of work to detail out all of the interactions that the program will have, but planning a successful piece of software is inherently a lot of work. The plan may take days to create, but it will save you many times that amount of time in the long run.
Start from the top. Assume that you have a working program, and break it down into its major components. Take those components and break them down into their constituent parts. Keep doing this with all of the pieces of the working program until you have them reduced to trivial tasks.
This part of the creation process also includes any research you have to do into things which you haven’t done before (provided that you know about them ahead of time. While a good plan will cut down on unpleasant surprises, it won’t eliminate all of them).
While doing this, keep in mind the three divisions of requirements and label each piece as to where it fits into that puzzle. This will help keep you from working on features which may get or have been cut until they are needed.
4) Start building
Now that you have the requirements and a detailed plan, you can start coding the application. Starting with the core components, begin building the application.
Start with the core features and work your way out through the “should have” requirements and then into the “could have” ones. The major exception to this is when adding a “could have” or “should have” will only take five minutes or so at the time you are finishing up some more important part because they are related.
If you make the statement “but this core function won’t work without this other less important thing,” then the other requirement isn’t as unimportant as you first thought.
5) Turn off the phone and lock the door
Take some time every day that you work on the project to completely tune out the rest of the world and work on the project at hand. This will lead to fewer distractions while doing your work which will, in turn, lead to fewer mistakes in the end product.
Your time is important. It’s not something you can get back, and mistakes cost a lot of time to fix. Keep this in mind and it will help save yourself time, sanity, and money (bug fixes cost you money in that they keep you away from doing new projects that pay your rent. Bugs also cost your reputation which, in turn, can cost you money due to lost projects).
6) Create the documentation as you create the application
Document the features, menus, etc while you create them.
Doing this will save your sanity in the long run. It will prevent you from trying to remember how in the heck you set everything up once it’s all finished and put together. It will also help show you if something you are writing is deficient so you can update your plan.
7) TEST EVERYTHING
I don’t think I can emphasize that enough. Test absolutely everything while you make it. Beat on every piece of the puzzle until you are sure it will stand up to everything short of an atomic bomb.
When you get a section of pieces finished which interact with each other, beat on those too.
After the program is finished, summon Murphy, his weapon of choice, the grand Cosmic Sledge Hammer, and his friend Machiavelli to rip the program apart. Treat it like the people using it will be malicious, demented, rabid monkeys on acid, because you’d be amazed at some of the things programs will be put through in the real world which you never thought of while you made them.
If something breaks, fix it.
When you’re sure that the end product is finished, ship it out. Spend time showing them how to use it. Be available for a while to answer questions without charge (and within reason).
In closing, keep in mind that requirements may, and often do, change during the program’s life cycle. It isn’t my intent to outline every step that I take when working on a project. It is simply to give a relatively brief overview on how I approach the problems.
The exact method I use for any given problem will, of course, depend on the problem itself and the circumstances surrounding it. Every problem is different, but they usually share some common features. Use that to your advantage.