At the root of almost all software development is the motivation to fix a problem. It’s not uncommon that a software developer might refer to themselves as a problem solver. With this in mind every developer has to ask themselves every day, “How do I solve this problem?”. Finding the correct method or way to go about solving a problem is immensely important and is a key component to any developers success. In this article I’m taking a deeper look in to what I think is one of the most important steps to problem solving, establishing the root of the problem a.k.a de-rooting a problem.
The root of a problem is the bottom most layer of a problem much like how a root is the bottom most layer of a tree. Lets take the example of an apple tree. The point of growing an apple tree is to pick the apples and eat them to increasing your overall health. Growing the tree in order to maximize yield you have to address it at the roots. This works largely the same way for a large percentage of problems a person might experience. When working on a software problem it really helps me to know what the underlying issues are to the problem or in other words the roots of the problem.
Let’s pretend I’m given the task of building a website. I might then ask the person giving me the task, “What’s this website looking to accomplish?”. The reason for asking this question is to get closer to the roots so I can water them in the best places to maximize the success of the project. Sometimes using a patch method or using some form of additive or extension is the best fix for certain problems because that’s the most efficient method. Sometimes you have to start all over and go from scratch because none of the existing technology is able to do what you want it to do. Knowing the root of the problem at hand, “I want to build a website that creates a subscriber list and emails me the details daily”, helps me to get closer to answer the question of “How do I go about solving this problem”, which is my definition of de-rooting a problem.
Obviously the above example of, “I want to build a website that creates a subscriber list and emails me the details daily” is a very basic and simple problem for some developers. Depending on the developer’s skill level that question may require deeper digging. Take this for example, there are two people of the same physical attributes, one has no tools and the other has a shovel. They are both given the task of uprooting an entire tree. Who is going to uproot that tree faster? Naturally the one with the shovel is going to get this done faster because they have better resources/tools to get the job done. This is the same with two developers given the same task of “I want to build a website that creates a subscriber list and emails me the details daily”. One of the developers might have researched and found exactly what it takes to get this done sometime in the past while the other developer has never done anything like this. The developer that has done this in the past is going to get this job done faster, assuming that the developer has a way of accessing that information/resource/tool they used before and they are able to apply it this problem.
A developer’s greatest tool/resource is information. I try to always keep my solutions to software problems stored somewhere so that I might access them in the future sometime with greater ease and efficiency. I’m quite sure there are many different ways of doing this. I typically create myself a folder on my computer for a specific project that contains information on how I solved the problems which as a side effect actually helps me solve the problem. If it helps to think of the information in more of a physical sense I also make backups of these folders/files to external drives, usb drives ect. Those drives are literally the tools that help me as a developer. An even more external example for developer tools are the servers hanging out at google helping me to access other servers for information.
It is incredibly important to know the tools that you have access to and how they work so that you might better effectively reach and execute upon the root of your problem/task. The more de-rooting you do, the better methods you’ll find to make future de-rooting more efficient. By consciously digging for the roots to your apple tree and doing it in the most efficient way you will yield better apples. The same is true for software development, the better you de-root a problem the higher quality of success you will attain.