Developers know that no matter how diligent and careful you are, when you least expect it, eventually things crash, and you find yourself in recovery mode. Even though every company and individual programmer has a few rules of thumb they follow, the worst can still happen.
Interestingly enough, a recent article in InfoWorld, written by Peter Wayner, points out that sometimes one developer’s “golden rule” is the extreme opposite of another’s. Neither are wrong, but taken too seriously and too far to the extreme, the worst can happen. Wayner demonstrates this theory by explaining the following programming mistakes:
Playing It Fast and Loose vs Overcommitting to Details
Overlooking basics brings out the simplest mistakes that then snowball into bigger bugs. In addition, using one big catch all for all possible exceptions can be a lazy solution that leads to more disaster. With that in mind, paying attention to every details and adding too much code will eventually slow down your application.
Not Simplifying Control vs Delegating Too Much to Frameworks
Not simplifying control over tasks in code can have negative implications. Wayner references one experienced developer who says there should be “One and only one place in the code for each job. If there are two places, odds are someone will change one but not the other. If there are more than two, the odds get even worse that someone will fail to keep them all working in the same way.” On the other side of the coin, relying too much on frameworks can make it difficult to troubleshoot because it’s challenging to find out what’s gone wrong in the code
Trusting the Client vs Not Trusting the Client Enough
Assuming the client device will always do the right thing can open up a number of security holes and vulnerabilities. Vice-versa, adding too much security to prevent any vulnerabilities is sure to slow things down, add clunkiness, and hurt the user experience.
Relying Too Heavily on Magic Boxes vs Reinventing the Wheel
Although extremely helpful, many magic algorithms have subtle weaknesses to them and the only way to truly get past them requires extra learning to truly understand what’s under the hood. You could try creating your own cryptography, but trying to re-invent the wheel won’t be as effective as what experts have already developed.
Closing the Source vs Opening Up the Project
Many developers today will advocate that closing the source on your project discourages innovation and hinders opportunity to uncover and fix bugs. In reality, though, there needs to be an incentive for outside contributors to put in the work and your project may not get any contributions at all. Not to mention there’s more overhead in managing an open-source project, like maintaining documentation.
Following Too Many Trendy Ideas vs Ignoring Too Many Trendy Ideas
Finally, who doesn’t want their project to be at the top of the game and taking advantage of all of the new bells and whistles? As you start implementing those new flashy items, beware that more work and challenges can arise because they’re so fresh. Don’t wait too long, though, because ignoring the trends will leave your code out-of-date and behind the times, which will eventually lead to bigger failures and malfunctions.
In any line of work, whether it be programming, other realms of information technology, or a complete other industry, flexibility is key. While it’s wise to follow best-practices, tunnel vision of those rules can guide you down the wrong path. We recommend reading the original 12 Programming Mistakes to Avoid by Wayner, as it provides extensive details on each of these.