12 programming mistakes to avoid

The dirty dozen of application development pitfalls — and how to avoid these all-too-common programming blunders

1 2 Page 2
Page 2 of 2

While openness can make it possible for others to pitch in and thus improve your code, the mere fact that it’s open won’t do much unless there’s another incentive for outside contributors to put in the work. Passions among open source proponents can blind some developers to the reality that openness alone doesn’t prevent security holes, eliminate crashing, or make a pile of unfinished code inherently useful. People have other things to do, and an open pile of code must compete with hiking, family, bars, and paying jobs.

Opening up a project can also add new overhead for communications and documentation. A closed source project requires solid documentation for the users, but a good open source project also needs extensive documentation of the API and road maps for future development. This extra work pays off for large projects, but it can weigh down smaller ones.

Too often, code that works some of the time is thrown up on GitHub in hopes that the magic elves will stop making shoes and rush to start up the compiler—a decision that can derail a project’s momentum before it truly gets started.

Opening up the project can also strip away financial support and encourage a kind of mob rule. Many open source companies try to keep some proprietary feature in their control; this gives them some leverage to get people to pay to support the core development team. The projects that rely more on volunteers than paid programmers often find that volunteers are unpredictable. While wide-open competitiveness and creativity can yield great results, some flee back to where structure, hierarchy, and authority support methodical development.

Programming mistake No. 11: Following too many trendy ideas

Trends often begin with a good plan to fix some gnarly problem. If we can just rewrite our code with a new language, framework, or collection of libraries, we can eliminate the difficulty. The plan usually ends up bearing some fruit. The trouble isn’t the cost of rewriting the code—although that is often substantial—it’s the shift to the new paradigm, which often leaves a mirror image of the failure mode. A yang instead of a yin.

The problems get worse if you need to accomplish anything substantial. Many of the newest ideas and frameworks offer only the important features. Everything else hasn’t been written yet. Sure, you’ll save some work on the features that are ready, but you’ll often write more of the glue, background, or filler code. Being on the cutting edge is hard work.

Programming mistake No. 12: Ignoring too many trendy ideas

It’s easy to dismiss the clever, cute, or ingenious new pile of code as folly, or as a capricious vanity project. Many of the times you’ll be right. But occasionally you’ll be wrong and then you’ll wake up to look at a stack of code that’s hopelessly out-of-date.

In the beginning, you can console yourself by focusing on the fact that the code still runs. Even long out of date code can function successfully for awhile. Eventually, though, bits and pieces will start to fail and you won’t have easy options. Perhaps some API will be shut down without leaving a forwarding address. Maybe a partner will stop taking XML files and you’ll be forced to launch a crash coding project to generate YAML or GraphQL results.

Technical debt isn’t a well-defined concept like monetary debt, but the philosophical debates won’t matter when it’s midnight and the code won’t compile because you’re stuck using version 2.1 of the compiler while the rest of the world has moved on to versions 3.0, 4.0, or maybe one of those non-numbered quantum leaps of nomenclature like NG. Pay now or pay even more later.

Copyright © 2019 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2