Planning well is the key to successfully finishing a project, and it does not solely apply to large projects. Even your small one file programs could really benefit from a plan before you start. If you’ve ever watched one of my videos, you’ll frequently see me drawing my intentions on screen – this is not just for a visual demonstration, more often than not, these drawings are inspired by squiggles I drew while I was planning the project. In this post I want to point out a few things that I do to ensure in the very least, I reach my project goals.
File > New is one of the most exciting and beautiful things. It captures the ambition and hope of the next amazing creation; allows you to put aside that mess you were making last night; marks the beginning of a new journey of exploration; and is potentially the single most important step of your next development. Those next few lines will dictate how you go about implementing that solution you’ve not thought through, not considered the workload, not evaluated the feasibility, given little thought to the logistics, yet is going to be amazing. You’ve made a repo, drawn a logo, come up with a name, you’re all good right? I mean what else is needed? That blank file is calling you, “code me, code me” it quietly screams. And then one of two things happens:
- You start coding aimlessly yet passionately. “It’s OK” you’ll tell yourself, “I’ll refactor and rewrite later”, right now you’re fingers are too excited. Let’s go go go! It doesn’t seem to be coming together, that’s OK though, it will, it will, you’re sure of it, after all, you spent 2 years writing your last prototype. Well done you! You’re a coding machine!
- Nothing. Whilst you think about where to start, you start considering your project might be better if it was a bit different, so you redraw that logo, rename that repo, and announce to the world what your next project is going to be. This is now the seventh new project this year. Well done you! You’re so productive!
So you have found some inspiration to actually make something. Great! Don’t ruin the opportunity by not giving enough attention to evaluating your idea beforehand. A feasibility study/assessment is the single most important task to perform, as it will guide you in producing a goal that is actually achievable, and will highlight areas that may risk your projects failure. Knowing when to let an idea go is hard, because you’ve got to deflate from 100% enthusiasm and excitement, to being back at square one. However, you’ll have given up the idea because you will have assessed it as not being suitable at this moment. It can be saved for later, you’ve not wasted any effort, and you have learned something about yourself, and that’s a fantastic currency to bank as you proceed with the next project.
Assessing Feasibility
Ambitious projects are never going to get finished if they are literally impossible to complete. There are several core components you should assess before undertaking them.
Is it actually possible?
Even though programming offers the potential to do anything, some things are simply not possible. You can’t write programs that require exabytes of memory, or 100GHz processors to operate sensibly. Nor are you going to compress things to 0.001%, or reduce communications latency to 0ms. One way to assess this is to consider these bottlenecks, how much storage? how fast communications? how many calculations? Try to actually answer these before you start, and not with made up numbers. Get that calculator out and do the sums. If the numbers get very large, or very small, you’re heading towards the “extremely difficult” – and that’s a severe risk.
Is it actually possible for me?
This is a tough one, because admitting your limitations takes courage, and common sense. Let’s take a simple example – a 3D graphics engine. There are many things you need to know before you can start. Trigonometry, calculus, geometry, linear algebra and matrices, graphics architectures, hardware APIs, real-time processor and memory manipulation, to name but a few. Nobody “just knows” this stuff, it needs to be taught and learned – and that takes effort and patience. Perhaps your project is a vehicle to learn about these things, that’s great, that’s how i learn, but you don’t want to learn all of these things at once, or else you’ll become barely skilled at any of them. This will lead to frustration, and demotivation – and that’s a severe risk.
Is the scope of the project sensible?
We all want to be creating software with the caliber of a AAA studio, or an industrial power house, but as an individual, you are neither. There is a reason companies we know and love cost billions of dollars to run, employ hundreds of skilled people and take several years to create awesome software. Perform a reality check. You are one lone coder (or a small team). What resources do you have to contribute to the project? How much time can you sensibly afford? Don’t forget you need to work, eat, sleep etc. How many and what quality of the assets does your project need? Do you have those skills? Are you prepared to create them all? Particularly with game projects, people prefer a well polished and cohesive product over a vast, directionless mess of mediocrity. I would love to have the London Symphony Orchestra, Pixar, Johnathan Blow, Bjarne Stroustrup, et al, at my disposal for my next project, but I don’t. If your small project requires vast, numerous or expensive resources before you’ve even started, it’s probably beyond your current scope – and that’s a severe risk.
Who is the project for?
It could be a customer, it could be for yourself, it could be for your friends, but knowing realistically why you are starting the project will help you justify if it’s worth it. Customers inflict deadlines, so you have to keep the scope under control. Projects for yourself are especially risky, because nobody is making you do it, if you don’t believe in it, it won’t happen (sounds cheesy, but sniper-like accurate). Projects for other people are actually a great motivator, but it can bring undue pressure in the wrong circumstances, so don’t commit to projects just to “be nice”. Try to find a way of ensuring you have a personal stake in the project, something to lose, but not something that’s going to hurt to much if it fails. Also run your idea past other people, but approach people outside of your echo chamber, they’re going to agree with you no matter what – and that’s a severe risk.
Making A Plan
So hopefully now you’ve taken a moment to reflect on your idea, and I’ll assume you’ve evaluated its feasibility, and it is something you can manage (albeit with a little learning perhaps). Its now time to plan your solution. I use solution in this instance, because phrasing your project idea as a question or problem that needs solving is actually quite a smart idea. “I’m gonna make Minecraft” is far less useful than “How do I make a cube based building game, where you find resources with which to build structures and utilities that progress me towards the end goal?” The question itself will prompt further tasks and goals.
- How do I draw cubes? Need a 3D engine
- How do i make a 3d engine? Use a graphics API
- How do I use a graphics API? Establish an input/processing/rendering loop
- …
- How do I use a graphics API? Establish an input/processing/rendering loop
- How do i make a 3d engine? Use a graphics API
- How do I find resources? Distribute types of resources in a world
- How do I distribute resources? Use a world generation algorithm
- How should I generate my world? Establish a mathematical model
- …
- How should I generate my world? Establish a mathematical model
- How do I distribute resources? Use a world generation algorithm
- How do I build things? Use an inventory, and a dynamic data framework
- How do I structure my data? Use a database, and an efficient storage device
- How do I define my data? Plan out what data you actually need
- …
- How do I define my data? Plan out what data you actually need
- How do I structure my data? Use a database, and an efficient storage device
- What is the end goal? Decide upon a condition for completion
- How do i make it worth while? Reward the player frequently
- How do I implement fun things to do? Create sub-goals or activities
- …
- How do I implement fun things to do? Create sub-goals or activities
- How do i make it worth while? Reward the player frequently
The above example is deliberately trivialized, but it has already broken down a large project idea into smaller manageable projects, which can be assessed and planned in their own right, and may lead to a useful outcome regardless of whether or not the overall project is successful. As much as possible, phrase all sub goals as a question, eventually there will only be an answer left, and at that point, you know what to start typing after clicking File > New.