Archive for 2010

Playing it fast and loose

Failing to prop up the basics is the easiest way to make errors in coding. There are a lot of small places where a developer may make a mistake which causes software to fail. And the worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. There have been improvements in syntax in programming languages. For instance, the latest version of Java tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. But such syntax improvements can only prevent code from crashing. They don't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.

Overcommitting to details

On the flip side, overly buttoned-up software can slow to a crawl. Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. Here, the challenge is to design the layers of code to check the data when it first appears, which is much easier said than done.

Not simplifying control

Not simplifying control over tasks in their code may invite disaster for developers. The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.

Delegating too much to frameworks

Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. The rules are, while quite reasonable, not entirely trivial. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge.

Trusting the client

Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.

Not trusting the client enough

Sometimes too much security can lead paradoxically to gaping holes. Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.

Relying too heavily on magic boxes

Many programmers assume they can link in the encryption library, push a button, and have iron-clad security. But many of these magic algorithms have subtle weaknesses, and avoiding these weaknesses requires learning more than what's in the Quick Start section of the manual.

Reinventing the wheel

Then again, writing your own libraries just because you think you know a better way to code can come back to haunt you. But grow-your-own cryptography is a welcome sight to attackers. Many libraries don't need to be perfect, so grabbing a magic box is more likely to be better than the code you write yourself.

Opening up too much to the user

Placing the onus on users to customize functionality they do not fully understand can invite disaster in the form of inadvertent security holes and privacy violations. When making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software.

Overdetermining the user experience

Some developers decide to avoid the trouble of too many features by offering exactly one solution. But if users don't like the idea, they will look for ways to work around these limitations, and it will lead to an outcome that could translate into security vulnerabilities.

Closing the source

The decision to not distribute code works against the integrity of that code and it can discourage innovation and fixing bugs. Just opening up the code forces you to make the info more accessible, understandable, and thus better.

Assuming openness is a cure-all

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. Opening up a project can also add new overhead for communications and documentation. Moreover, a good open source project comes with extensive documentation of the API and road maps for future development.