The 7 deadly sins of software development

Recognize the worst traits of programmers everywhere and save yourself from developer hell

Page 2 of 2

Fourth deadly sin of software development: Sloth (not validating inputs)

The list of basic programming mistakes is long, but the sin of failing to validate input is so pernicious that it bears special consideration. Why this seemingly amateur error still crops up in code written by experienced programmers is baffling. And yet, many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it for correct formatting.

Modern programming languages provide many tools to help coders keep this from happening, but they have to be used properly. Remember, a Web form that uses JavaScript to validate its inputs can be easily sidestepped by disabling JavaScript in the browser or not using a browser to access it at all. Input validation should be baked into the core of your application, not sprinkled onto the UI. Anything less is simple laziness.

Fifth deadly sin of software development: Wrath (not commenting code)

What act could be more hostile to your fellow programmers than failing to comment your code? I know, I know: Well-written code is its own best documentation. Well, guess what? Those methods you wrote at two in the morning last Thursday weren't exactly well-written code. (And if you're a Perl hacker, you owe me nine Hail Marys.)

It's easy for programmers to forget that the code they write today may live on long after they've left the job. To the programmers who replace them falls the unenviable task of figuring out what each snippet of code actually means. So have mercy, and leave them a few hints.

But remember, unintelligible comments or commenting too much can be as bad as not commenting at all. Comments like "this is broken" or "don't touch this ever" aren't much help to anybody. Neither are redundant comments explaining simple operations, such as variable initializations. Code is its own best documentation of what it does; comments should be there to explain the why.

Sixth deadly sin of software development: Envy (not using version control)

It's hard to believe there are still software projects in 2011 that exist as a directory tree on a file server, jealously guarded by one "master maintainer." Scattered around the office are duplicates of this tree on individual developers' workstations, each slightly different -- though no one knows exactly how.

Maybe you have reasons for not implementing version control on your projects. Maybe it started small and just got out of hand. But powerful, effective version control systems are readily available today for free. Service providers are even available to host code for distributed projects for minimal cost. There is no reason why you shouldn't make starting a code repository one of the first steps in any project, even small ones -- unless, that is, you can't stand to see anyone commit code changes but yourself.

Seventh deadly sin of software development: Pride (not unit testing)

It's often tempting to pat yourself on the back for a programming job well done. But how do you know it's well done? What are your metrics?

Unless you've validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of defects. But all too many developers fail to produce unit tests for their code. They claim time spent testing is time not spent implementing features. In fact, some developers fail to even write QA testing into their project budgets.

What can I say, except that pride goeth before a fall? By the time defective code arrives in the client's hands, it's too late to undo the mistake. The more you plan for unit testing before your code ships, the more damage control you can avoid later.

This article, "The 7 deadly sins of software development," was originally published at Track the latest developments in programming at, and for the latest business technology news, follow on Twitter.

| 1 2 Page 2