Execution without thinking through an entire situation or pondering the “what ifs” is a common problem that has dire consequences in more then just the field of programming. Yet, this simple practice of owning the concept of forward thinking can make a huge difference in your programming and final products. There are a plethora of ways that looking ahead and avoiding taking shortcuts can affect a programmer and the final code produced.
I cannot tell you how many times I have seen programmers jump into a large application and just start adding or changing logic without looking at the bigger picture. Many times, this situation arises when there is a need to get the code completed in a short time frame. However, one must think about the long-term effects this has on a product life cycle. We have all been there and faced situations similar to this. Instead of discussing the importance of review, research, and discovery with the person managing the project, some just jump in and get to work.
There are so many issues that can arise from this “git-r-done” attitude. The consequences that can arise from this short-sighted thinking many not rear its ugly head for quite some time, yet these kinds of mistakes are almost always difficult to correct and thus become time consuming and costly to fix. Unfortunately, I am often tasked by new clients to fix projects that are plagued with these kinds of issues. Spending an hour or less and looking before you leap can potentially save days if not weeks of unnecessary work in the future.
In the programming world you hear a lot about “QC, QC, QC”, and while QC is undoubtedly important, spending the time to think forward with your programming is equally, if not MORE important. QC finds bugs at face value, but those hidden demons that are forged from short-sighted thinking are the ones that can haunt you and your project for a long time to come.
Earlier in the week I was tasked with a modification to a rather large existing web project. The task was to add a small piece of functionality to this rather complex spider web of code. This project lacked documentation and was one that I was not familiar with. I spent more time reviewing code then I did actually programming - and thankfully I did. Nothing within the program was what it appeared to be at face value, and there was no shortcut to the discovery phase of the programming. Had I jumped in and started to code, I would have missed two important functions that I discovered. Had I missed these pieces the consequences would have yielded a horrible outcome. The project would have passed QC, and by the time the issues started to appear the amount of work it would have taken to correct the data would have been astronomical. I leave you with this thought: the most effective QC is proactive QC and not reactive QC.
So my friends, go forward and think forward.