Coming up with Engineering Solutions that Matter

I had a conversation with my brother a while back where I was trying to pick his brain on how someone could figure out a problem(s) to solve using engineering techniques. My brother was a pretty solid candidate to pick since he's an engineer, (yes this is a family of engineering kids, parents sought their fortunes elsewhere).



I have been to quite a few technology expos in and around Nairobi and more often than not, I feel like there is a lack of inspiration to the solutions on display. It's not that the projects aren't cool or fascinating, it's just that most of the projects on display will not have a life beyond the expo because I don't actually see them actually being applied in the real world. To be fair, this is a problem I typically face when thinking about joining any kind of competition, how do I come up with a project that lives beyond the event and isn't just a rehash of some previous winning project (ahem, automated irrigation). So I asked my brother, if someone wants to come up with an engineering solution to a problem, what do they do?

His advice was that one should first find a problem and define it in plain English (or whatever language you are most comfortable expressing yourself in), before trying to engineer a solution for it.

But what does that mean? Is this just some Yoda nonsense advice that actually sounds wise but leads you nowhere?

Not really. It means that you should not start thinking of a project by saying, "Hmm, I have an Arduino, what problem can this Arduino solve." Start by asking yourself what problems exist around you. After identifying a problem, you can go ahead and start figuring out a solution for it.

One of the reasons why you shouldn't let your tools take precedence when coming up with a solution is that you will fall into what my brother called the hammer problem. The hammer problem is where if the only tool that you have in your toolkit is a hammer, then suddenly all problems will start looking like nails to you. So even if your hammer isn't the best tool for the job, you will try to convince yourself that it is.

Coming up with the problem statement is arguably the most difficult part of a project because there isn't a winning formula that you can easily follow. A good problem statement I think has to come from a point of understanding and empathy, you need to know the person for whom you are designing the solution for and their needs. One of the easiest people to design a solution for is yourself, or even the community around you. This is really easy because you know personally where the shoe pinches.

If you however you need to solve a problem for a community that you aren't explicitly a part of, then you've got to do your homework. You've got to do your research and understand the challenges that they face. Then once you've done your grueling assignment, you can start figuring out how you need to approach the problem to get a useful solution.

Once you have a problem, and you define it properly, you can then ask yourself, how you can solve it using the skills you have, what would you have to learn, and if you are to assemble a team, what kind of person would augment it.

So while coming up with a problem statement isn't really a fun part of a project, it really does set the tone for whether you project will actually be of use, or just junk to be discarded.