Ideas are a fickle, elusive thing. They come to us in droves, or sometimes not at all. Some revolutionary ideas make their creators go down in history, while many others give much more modest returns.
Regardless, the ability to act on and execute ideas is arguably one of the most important skills one can learn.
So, in the spirit of learning something new myself, and hopefully helping newer coders or people with a new, unique idea or take on something related to tech, (but without the technical expertise to understand what might go into it), I start this series of articles, where I document and condense into easy steps my own journey, going from a vague idea about a project to learning exactly what technologies need to be used in it, exactly what a minimum viable product for the idea in question would look like, how the pieces will all fit together, etc.
Through the research needed for all of this, exactly what the feature set, target audience (and if applicable) commercial viability of the idea in question would be is automatically found out too, so thats a major plus.
Before we get started though, I’d like to share some small, but extremely valuable advice I had to learn the hard way, through my first ever project.
Firstly, always keep in mind that software doesn’t ever get “finished”, but does get shipped.
Don’t get caught up on perfecting small things (those can be done later, in any of the hopefully multitude of future updates), but rather, focus on the core functionality, the real “meat” of the project, and make sure it works reliably, consistently and predictably. And then, ship a stable first version.
Software that has shipped, actually been out there, being used by and helping real people, in the real world, is miles better and tons more motivating to work on than software that never sees the light of day because its in a perpetual cycle of being “perfected”.
This is NOT to say that releasing a version 1.0 should be the top priority. Nowadays, driven by impatient investors and stockholders, software that should clearly have been given more time to develop find their way out of the code editor and into the real world.
And this can lead to a wide variety of problems in the future, from headaches for the devs maintaining and upgrading the codebase to system crashing errors and dangerous security breaches for the users, depending on the reach and scale of your software.
It only means that how the dials and buttons look should be a much lower priority than, say, the algorithm that lies at the heart of your project, and that a working, efficient and most importantly, usable version of that should be the top priority, followed closely by releasing it as a version 1.0 (or better yet, as a beta) and garnering feedback for a better next version.
Secondly, understand that a project is nearly always larger than you first thought, and that it WILL take a good amount of time (and consistent effort) to get off the ground and to a presentable, working state.
Proper planning can help ease this greatly, but a software project will always take time and effort, and will naturally be frustrating at times, and that’s without taking into account all the unexpected problems and gotchas that might come your way.
Know that time spent doing what you enjoy is never wasted time, and that what you learnt in the process will stick with you forever.
A passion for what you do will therefore be your greatest asset in combating the feeling of inadequacy, frustration and impatience that might all pay the occasional visit.
So, you have an idea for software, in any of the plethora of forms it comes in. Where do you start ?
Well, if you’re reading this, chances are you’ve already googled it, quite a bit too perhaps, but, I would suggest you first sketch out the idea a bit more.
The idea may have come to you suddenly, with random thoughts stringing together to create something more, something meaningful, or it may have been a fair bit longer in the making. But regardless, I implore you. Sit down, and flesh out the idea.
Don’t worry about the specifics, the how, just yet, but rather focus on the why. Really understand what it is your idea does and what problem(s) it solves.
As a general rule of thumb, you know your idea well enough if you can answer without much deliberation these questions:
- What your idea does (or does better than the competition)
- Why your idea would be helpful or attractive to others
- Why people would choose your idea over alternatives
- Who are you trying to help with your idea
By actually taking the time to answer these questions, you’ve already begun the first (and most crucial) stages of planning, and have ensured that you have a strong base to hit the ground running, as these questions help solidify the core parts of your idea that everything else connects to and references.
The Next Step
The next step, after having an idea sketched out, is to come up with a rough list of requirements, and these can usually be found easily as by now the idea has some solid groundwork and you actually know what you have to do, just not how to go about it.
There isn’t really many well defined “steps” that you can follow here, as each idea is entirely unique from every other idea, and as such is backed up by an equally unique set of requirements.
The only real advice I can give here is what worked for me, which is incessant googling. The few tips I can give regarding this ancient practice of google-fu, are:
It’s all a big game of Hot and Cold. No, seriously. The best way to google, especially for hyper specific information (like say, the unique requirements of an idea) when you don’t know anything about how exactly to phrase those queries, is to describe the function in the simplest, most concise form you can, and building off of the results Google gives you.
Gradually, and usually only after a few consecutive searches, you end up finding something specific and related to your idea, but whether that is really useful for your scenario is still usually determined purely by chance.
The most important bit to come out of this, however, is that now, through the reading material that you’ve undoubtedly sifted through to get to that specific technology that offers a version of the function you require (but most likely not suited to your needs), you know the terms and the lingo that best describe and relate to your query.
And now you rinse and repeat, gradually converging on the specific terms you need to pull up the specific technology best suited to your needs
The second tip I can give, is that, no matter what, steer clear of the rabbit hole. By this I mean not retracting and searching again after you’ve found some better search terms, and instead just drilling down into the one technology you found.
Now is not the time for that, and this will more often then not lead you to feel frustrated and overwhelmed. You’re just scouting and judging the terrain now, not building a castle there right that instant.
Thirdly, and this is more warning and advice than a tip, but please, please, PLEASE, don’t get hung up on choosing the “perfect” technologies for the job.
Find the ones that offer most of what you need from a few options for each, and just start. Getting hung up on the “perfect” tech stack is, to say the least, the perfect way to never actually start working on the idea.
Do note however, that the opposite, jumping into the first thing you find that’s even remotely related, is also a surefire way to ensure headaches later on.
Research and compare, but don’t get hung up on minor differences or inadequacies and trying to find the perfect fit, because 9 times out of 10, there isn’t one.
As your list of know requirements gets longer, you’ll start to even better understand the true scope of your project, and also be able to better assess what the other requirements for your idea are, including finding any that you may have originally not realized needed to be included.
This is great work, and all thats left now is really polishing and defining the gaps and fuzzy areas, and your idea goes from a sketch to a plan.
By now you should have a good understanding of what your idea is and does, and you should also be able to concisely explain it in a few sentences, as well as have a basic list of what you’ll be using to build it (or what skills you’ll be looking for when hiring someone to build it for you).
In the next post, we’ll look at my idea, and I’ll walk you through me following the very steps I laid down for you in this post, going from a vague, shower thought of an idea to a more well defined, thought out one that’s even backed up by a rough list of requirements!
Until next time!