Brick by Brick: Planning before programming and Agile Development

Brick by Brick: Planning before programming and Agile Development

In 2016, I attended a 2 week creativity and robotics program called the Ashesi Innovation Experience. It was great; although I didn’t learn any new programming skills, I learnt a lot about creativity and whatnot. However I did learn one very important programming concept that I hadn’t given much thought to before.



Now I’m not talking about being some kinda modern day programming Bobby Fischer and memorizing all the plans for your software in your head. No, I’m talking about planning on paper.

If you feel a bit taken aback by this seemingly preposterous notion, you’re not alone. I had the same feeling when those new programmers were advised to whip out some A4 sheets and start scribbling down what their robots were supposed to do in English before they typed out the commands in their IDEs.

I decided to “humor” it and tried it out.

Boy was I surprised at how it made things ways easier. I no longer had to focus on why I’m making it do any particular thing (or how all its actions will eventually achieve the goal), but how I’m going to put those instructions into the pretty basic Robot C we were using at the time.


A little foresight can’t hurt

More than a year later, I still keep that advice at heart, even though I practice it at a smaller extent than I did at AIX.

Planning before creating a program or system can help tremendously when you’re programming. It gives you some foresight into problems you might face, can reveal weaknesses in your potential system, and makes programming the software altogether easier as you have an idea as to where you are headed every step of the way.

Admittedly it can take some of the fun away from the process (who doesn’t like a little improvision during programming sessions?), but also saves you from a lot of potential frustration and disappointment.

I think the analogy of building a house can work here. Architects have the their designs in their heads initially, but when they draw them out they see improvements that can be made (I’ll talk more about that in this post), problems that might be encountered, and overall get a better feel of what’s going on.

I mean, building the house outright brick by brick could prove to be fun and exhilarating, but making a mistake would be pretty disastrous. We’re programmers, and I know we can just correct our mistakes by smashing the backspace button a few times, but as your programs grows, problems will take much more time and thinking to fix since a ton of aspects of your program would be have been linked or based off to that problematic part by the time any issue is noticed.

A few backspaces won’t help in situations like this, I can assure you.

I’ve run into problems like that, and I’ve even had to shelf a game before because I went straight into making the game without realizing that one of the game’s core designs went against the rules of the game engine I was using. Planning on paper could have avoided that.

Keep in mind, however, that for some smaller things, planning isn’t always necessary. For small modules or projects, things are pretty safe in your head. But as things get more complex, paper can do some good. This is especially true for programs that deal with a lot of abstract things (for a simple example: a program that deals with the saving and loading of player profiles in a game where the player’s stats are intertwined with the game environment).

Okay so I think you get the message: planning forehand is important. But a good question to ask is: How do we go about planning?


Waterfall vs Agile Programming

Before I continue as to how to plan before programming, I want to quickly look at two interesting and conflicting programming methodologies (don’t worry, it won’t take too long).

The first one is called waterfall programming.

The conventional (conventional is important here because there are improved waterfall models) concept of waterfall programming is that software engineering is a linear process. Steps of development are carried out one after the other and are rarely revisited. You plan the software once, develop it once, and test it once (going back to fix the pesky problems you find).

You can kinda find the issues with this methodology outright. It presumes that that one plan you make will magically work without needing to re-plan or rethink things. It also presumes that during development, no hiccups will occur that will rudely throw you back into the planning phase.

Come on, we all know that programming isn’t always that smooth.


The second methodology is named agile programming.

Agile programming is more suited for larger projects with teams, but it can be applied everywhere. Agile programming is essentially the opposite of waterfall programming – instead of making the program in one fell swoop, you make it progressively in iterations.

You design and create the first program (the first iteration) then evaluate it. The first iteration should at lease satisfy some of the core requirements of the software. Then you’d look at what new features are needed, how it can be improved, and the likes. Then plan and create the second iteration and repeat the cycle. Agile development is more of a constant cycle of “make”, “release” and “make better.” No iteration is really considered the complete project (until maybe around the end stages); agile development really shines in environments where the requirements of the software change periodically.

Agile development has its issues too though. If the changes inbetween iterations are not that huge or significant, then the time spent on overhead (activities like planning, holding meetings, drinking coffee…) piles up, wasting a lot of time (since the time spent making the new iterations is not worth the added value they bring). Also, it could take a while before a proper spanking-awesome product is made.


A Balanced Diet

Ahh…I told you it wouldn’t take too long! Now back to the subject at hand!

The best way to plan for a program is to plan with both of these methodologies in mind. Strike a balance.


Plan beforehand, of course. Get some paper, draw some things out (if you want to draw), write some things, just be sure you know what’s actually going into the computer. It shouldn’t take too long, maybe a few minutes. But have a bit of a waterfall mentality here – plan such that the resulting software will satisfy most or all of its requirements, at least at their minimum (you can plan to have a few iterations afterwards to improve and polish your work).


Don’t overdo it though.

Don’t over-complicate the design and inner-workings. You’re planning, yes, but don’t overthink your designs just because they now have some form of plan(we all fall into this trap sometimes). As the programming saying goes, “Keep It Simple, Stupid.” Keep the plan simple yet thorough enough to serve its purpose.

Also remember that you’ll spend time debugging all those pesky issues that come up for no reason while you’re programming, so a simple plan is best for the beginning as some time is saved for debugging.

Once you’ve made some progress actually programming the software (and getting it’s base functionality down), then you can stop and think about what might be necessary to add. Eventually, however, you should stop iterating and take your current work as the final product. You don’t want to be iterating forever.

Be tasteful though.

 Don’t add features just because they might be useful in the future. An attitude like that is usually best for large projects (often commercial) where the software is going to be used and reused several times over. In such situations, leaving in some additional plug-and-play features in the software can make things easier. However, so smaller projects, add features that are worth the time they take to add, and still serve or support the main purpose of the software.


That’s all folks!

Phew! I think I’ve said a ton here. So lemme sum it up:

  • Planning is important.
  • For larger projects, take a few minutes to plan what’s going on
  • Don’t overthink the planning. It should be simple, relatively fast and thorough.
  • Be tasteful with your iterations and features – not every feature is necessary.


I hope you can take some of this advice to heart. Planning can be long or short, depending on the situation, but embrace it. Don’t grow fond of avoiding that crucial stage. As I said – don’t overdo it. It should be sweet and simple. That way, you have ample time for the good stuff that we all love – programming.



XB Software

Haylem, JeffO and Morgan Herlocker of Software Engineering Stack Exchange

XKCD comics


The owner of the Loading Developer blog and the Lumberjack Apps studio.