During a difficult time, a long time ago, I was faced with a problem that seemed to have too many moving pieces to imagine at once, let alone solve.
This is the technique I developed to help.
It goes like this:
- What are you trying to do? (write it down, seriously)
- In what way can you do that? (without listing specific technologies)
- What specific services will you use? (app, server, website, desktop app)
- What specific technologies will you use? (android, tomcat, angularjs)
- Get to work.
The nitty gritty:
What are you trying to do?
It's easy to have a partial, and wrong, solution in our minds that leads to a confused combination solutions. Spelling out what the problem is, as clearly as possible, often helps you see what the answers could be.
And this must be spelled out without any technical jargon whatsoever. This explanation is what you tell your (presumably non-technical) grandpa, when he asks what you're working on.
Here you might say “I want parents to be able to know how their kids are doing at school”.
Write It Down
Most importantly, write it down. Now that it's so simple that you can tweet it, you might think you won't forget. But you will. Everyone always does. And this is the part that no-one believes, try it for yourself, I guarantee you will forget this explanation and will have to re-create it 5 minutes later if you don't.
In what way can you do that? (without listing specific technologies)
Now that you know for sure what you're trying to do, you're ready to think of how you will do it.
This is the point where you release “you'll need the user to be able to access the program/ data from it has to be stored somewhere else/ some processing will need to happen on it / the results come back to the user.”
At no point do you name a technology. Notice the lack of the words 'app', 'server', 'computer'. You may realise the best way to do this is a desktop program, or maybe it just needs a website or something else entirely.
The more you avoid locking yourself into a technology with your words, the more free you will be to decide the details. If you got implementation detail into the description at this point, you've already locked yourself into a road that may not be the best one for your product.
What specific services will you use?
Here's where you decide that that you want an app, that talks to a server which will eventually get the details back to the app. Or a website that does the processing on the spot and shows people what they wanted.
Note you still haven't chosen whether it's android or iOS, (or both but which first?). Whether you're going to use Tomcat or Firebase on the server side. And which of the billion JS technologies you'll use for the site.
What specific technologies will you use
Now that you have a pretty good idea of what you want to do and how, you have a spec sheet what you need your technologies to do.
It's much easier to go out and find (or build) a technology that does something specific, that you need, than go out blind and pick the current hot thing.
With your previous lines written down, you know exactly what you want and can home in, making the right budgeting considerations for your tech. So you can finally…
Get to work.
Your ducks are in a row, you've got the right products, you've got a plan, now all that's left is to carry it out.
Good luck! And at any stage, if you see small hurdles or seemingly insurmountable issues, you can look up this chain and see where you had a bad assumption, or where you need a change to the tech.
This framework has helped me solve problems that were beyond my capabilities at the time, I hope it helps you too.
Let me know if you have any questions in the comments below or reach out to me on twitter at @AniketSMK
Top comments (3)
I've always struggled with part 2, trying to stay tech agnostic is harder than it seems, yet, it forces you to open your mind to new possibilities and opportunities.
If you struggle like I do, imagine you are explaining the project to someone who is not tech savvy or to a kid. Use simple everyday terms and try to summarize individual actions into a one-liner.
Really nice way to look at problem solving :)
Uncle Bob (Robert C. Martin): "A good architect maximizes the number of decisions not made."