Programming mistake No. 7: Relying too heavily on magic boxes
Worried about security? Just add some cryptography. Want your databases to be backed up? Just push the automated replication button. Don't worry. The salesman said, "It just works."
Computer programmers are a lucky lot. After all, computer scientists keep creating wonderful libraries filled with endless options to fix what ails our code. The only problem is that the ease with which we can leverage someone else's work can also hide complex issues that gloss over or, worse, introduce new pitfalls into our code.
Cryptography is a major source of weakness here, says John Viega, co-author of "24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them." Far too many programmers assume they can link in the encryption library, push a button, and have iron-clad security.
But the reality is that 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. To make matters worse, simply knowing to look beyond the Quick Start section assumes a level of knowledge that goes beyond what's covered in the Quick Start section, which is likely why many programmers are entrusting the security of their code to the Quick Start section in the first place. As the philosophy professors say, "You can't know what you don't know."
Programming mistake No. 8: Reinventing the wheel
Then again, making your own yogurt, slaughtering your own pigs, and writing your own libraries just because you think you know a better way to code can come back to haunt you.
"Grow-your-own cryptography is a welcome sight to attackers," Viega says, noting that even the experts make mistakes when trying to prevent others from finding and exploiting weaknesses in their systems.
So, whom do you trust: yourself or so-called experts who also make mistakes?
The answer falls in the realm of risk management. 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. The library includes routines written and optimized by a group. They may make mistakes, but the larger process can eliminate many of them.
Programming mistake No. 9: Opening up too much to the user
Programmers love to be able to access variables and tweak many parts of a piece of software, but most users can't begin to even imagine how to do it.
Take Android. The last time I installed a software package for my Android phone, I was prompted to approve five or six ways that the software can access my information. Granted, the Android team has created a wonderfully fine-grained set of options that let me allow or disallow software based on whether it requires access to the camera, tracks my location, or any of a dozen other options. But placing the onus on users to customize funtionality they do not fully understand can invite disaster in the form of inadvertant security holes and privacy violations, not to mention software that can prove too frustrating or confusing to be of use to its intended market.
The irony is that, despite being obsessed with feature check lists when making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software. Too often, extra features clutter the experience, rendering the software difficult to navigate and use.