When you’re designing new solutions, troubleshooting an issue or working with an existing bit of code, it’s easy to get caught up in the most elegant solution to the challenge you’re facing.
At times, this can add surprising complexity as you work through all the things the problem you are solving may involve.
Sometimes though, it’s important to take a step back and start at the beginning again. Beginning, as in the easiest solution to the problem. I know that many times I tend toward the "oh, it MUST be this" solution rather than starting with simple ideas. I’ve seen this a few times of late – here are some examples:
– we have performance issues on a server. I started digging through the logs, couldn’t find the issue. Dug through the code… couldn’t find the issue. Testing ideas, no dice. Just really couldn’t get it figured out. Turns out a simple reboot of the system solved the problem (sure, rebooting a production system isn’t the solution many times, but you know what I mean). It also let us find the issue of a memory management issue with an application. Rather than re-writing the world, looking for the complex solution, etc. – the answer was to start with the basics.
– an application just "broke." You know how it goes. Your application is fine, everything is humming along, then BAM! For some reason it just stops working. We scrambled, looking through line-by-line of the code. No problem found. After all, the code had been running literally for years. But it was broken! What else could it be! No other log issues, no other indication of what’s going on. The solution? Hey, let’s rewrite the routine. Just say no. We found out there was actually a data error – something very easily corrected – then we were back on our way. The simple solution – look at the thing that WAS changing – the data.
Just take a step back – eliminate the simple or more basic steps first. Then move slowly into the more complex. It’ll save time, but most of all, sanity.