One of the common problems many developers have, regardless if they are working on a personal project, working on a team or even working in the enterprise environment, is answering the question “When is it done?”
If you have spent more than a day around anyone in this field you are likely to have heard the term “Feature Creep”.
This quagmire tanks project deadlines more often than you would think. When you start your project you plan on creating a simple window that lists all the files in a directory. By the time you finish your app has 7 RSS feeds, a menu for your local pizza place and sound effects for every UI event.
Don’t let this be you…
Just as if it were yesterday I can remember my Drill Sgt saying, “Fail to plan and plan to fail troop!”
He was saying plan on not catching a bullet with your face, but the analogy works here as well.
When I first was looking into becoming a software engineer, a childhood friend of mine told me that 70-80% of programming was done on a whiteboard. I don’t do quite that much planning before I code but I do think that the more time you spend on paper or a whiteboard, the less time you will be debugging ridiculous problems that seem to popup.
So how do you start?
It’s really not that hard, start with the simplest thing first.
The first thing you really want to do is just identify the basic structure of your program. Write down, in plain old readable English, what your program should accomplish.
Is it going to be a twitter app that allows you to easily share recipes?
Are you creating a drink mixing app?
This is a very high level look at it, nothing more. It’s important to physically write this down. Set it in stone so to speak. It can be altered down the road if you need to but in reality you want it to be a constant.
From here you can start defining features. Okay so we want our app to be a bowling app. It will have the ability to track multiple lanes at once. When a game is complete it will be able to store all the scores from that lane’s players in our database and push it to the web. These features should be bullet pointed.
You can start to organize your thoughts here into categories but we haven’t discussed any UI or code yet. This is still very high level.
Alright now that we have our features chosen we want to start discussing UI flow. Once again, very high level. You want a main menu, a score tracking screen, a settings screen, a finished game screen and a high score screen.
We can take our featured bullet points from above and assign each one a screen.
Organizing it this way will quickly illuminate screens that might not be necessary and also make you aware of screens that might be cluttered and need to be split.
Once you have your screens decided on you can start hand drawing UI elements. This is where we are going to start getting into the nitty gritty of the positioning. Don’t worry as much about color schemes. You can do that here if you would like but your main objective is going to be what elements you need and their position. Having your UI well thought out beforehand will save wasted cycles that could be spent on cranking out code.
Alright so now we have our program pretty well structured on paper. From this point it is much easier to decide on who gets what workload, what needs to be cut and what needs to be added. It should also be much easier to forecast your total construction time from here as well.
This isn’t a perfect system, nothing is, but this is one of the workflows I use when planning projects. I use this for my personal projects, I use this during my full time job and I use this at competitions.
If you are able to lay out everything beforehand you will see how easy everything comes together. If you are doing competitive coding then you will appreciate the amount of stress this takes off your chest when the chips are down. While other teams are arguing over whose fault it is that their main page and their final page have no way of communicating you and your team will be comfortably cruising along knowing all your pieces will fit.
Really the moral here is that you don’t want to start coding blindly. Make a plan and stick to it. That’s how work gets done.
Author: Anthony Russell
