There’s nothing particularly flashy about standing in front of a whiteboard and planning out a program. It isn’t really fun. It’s way more fun to dive in and just start coding. But diving in can lead to unexpected problems – especially for someone without much programming experience. Without some planning at the beginning, it’s easy to get lost in the details. It’s harder to step back and define what you should be doing and, perhaps more importantly, how you should be doing it.
So even though it isn’t a flashy or fun topic, I wanted to right up a post and go over what planning out a program should look like. Here I am listing my steps to planning out a program. Keep in mind, these are official. I’ve linked to a few more ‘official’ links from universities at the bottom of this post. But like many strong opinions you’ll find regarding programming, this is only my opinion. If there’s a way that works better for you and allows you to complete your program faster and/or better – please, do it that way! (Also, write a blog post on it and send it to me.)
1. What problem are you trying to solve?
All programs come from a similar place – trying simplify something or solve a problem. If you don’t have a good idea of the problem you are trying to solve, you probably aren’t going to get very far. If you’re trying to solve a very complex problem, I recommend breaking it down into multiple smaller problems. This will make it easier to program in little chunks which is not as overwhelming as building an entire program.
2. How are you going to solve this problem?
I am a big proponent of sketching this part out. I’m very visual, so if I can see how it’s going to work, that really helps me. Basically at this point, I like to break down what should happen once the program is opened. I’ll use a game as an example of planning.
Let’s say that I’m tired of all these guys trying to date my sister. Because I am not prone to violence, I decide to make them a video game instead, in hopes of scaring them off. (I am actually working on something like this, and if you’d like to laugh at my first attempt, you can see that here.)
User plays game as me --> a guy tries to take my sister out on a date --> player uses the arrow keys to navigate to the guy --> player uses arrow keys and spacebar to beat guy up --> repeat until game ends
The important thing to notice here is that I have planned out the general idea of the program, from start to finish. I could also focus on each action and break that down into a plan as well, but for the sake of time, I’ll leave that out of this.
3. Special considerations
I am hesitant to give this one a number, because you should really keep considerations at the back of your mind for the duration of your project. Considerations include your user base, and which machine they will use to access this. Which browser will they use? What are their technical abilities? These are not things you want to consider when you’ve completed the program. Consider these at the beginning and allow them to guide development. After all, what good is a piece of software that your target users cannot use?
4. Build it!
This part should be pretty self-explanatory.
5. Testing 1..2..3..
I personally do not wait until the end to test my code. I am testing it as I add new features and functionality. I also test at the end to make sure everything works as it should. But that is more for polishing purposes. The ideal situation here is to have tested and planned thoroughly enough so that I am not stumbling across any major functionality issues at this point. I might notice one or two things, but they should be very minor.
6. Show off your code!
Put it on GitHub. Blog about it. Tell everyone!
Questions? Tweet me!