I'm glad the SANS Institute released its list of "top 25 most dangerous programming errors" in a bid to raise awareness about the omissions which make software vulnerable to deadly security breaches. However, security-clueless coding isn't the only thing responsible for software that sucks. Sadly, most people in the industry know what the problem is. So why doesn't anyone ever do anything about it?You old-timers -- programmers who worked in the business before the PC industry kicked the waterfall development model to the curb -- know what I'm talking about. That waterfall model was replaced by a process (and I use that word loosely) where the modus operandi was to cram in as many features as possible before the shipping cut-off date, and then fix the problems in beta. (Sure, I know time pressures mean waterfall wasn't rigidly adhered to, and also that it had deficiencies, leading to the 1980s flowering of alternatives like agile-development and object-oriented programming. But at least we had a model.)
It really makes you wonder where we are today, when one sees that two of the top problems on the SANS list are improper input validation and improper access control (authorization). (I'm guessing there's also not much thought given to writing error catches. Probably the SQA or test folks have to tell today's youthful coders to add that stuff in afterwards.) Other goodies on the list include "hard-coded password" and improper initialization.
I guess you can't make this stuff up, but if it's as common as SANS says, I don't know if there's any hope at all.
OK, so I don't want to come off as some software grandpa telling the kids to get the heck off my lawn with my Cobol-loaded (actually, C) shotgun. But I do think it'd be a good idea if they were more familiar with some of the canonical works which mull the mysteries of software development, and offer up some ideas for doing a better job. (This is doubly apt because Satyam's troubles might lead to a rethinking of the "outsource everything" model.)
Two books in particular come to mind. There's Fred Brooks's 1975 classic, The Mythical Man-Month. (Wikipedia entry here, Amazon here.) The author, a one-time IBM manager, came up with the time-tested aphorism that throwing more programmers onto a project that's running late will only make that project even later.
My other favorite is Gerald Weinberg's The Psychology of Computer Programming. (There's a short excerpt posted here.) Weinberg's book isn't loaded up with one-liners, but rather provides an almost Freudian dive into the personalities of the people you work alongside. When I read it in the late 1970s (it came out in 1971) I was blown away by its dead-on-ness. (I'm guessing that hasn't changed much, though thankfully I have.)
Software smarts aside, it's probably the case that the Web is simply too wide-open to stanch the majority of security threats. Which I guess makes it even more important for developers to develop a sense of software history. Because even the lowliest maintenance programmer stands on the shoulders of computer-industry giants. (That link is to Katherine Davis Fishman's 1982 The Computer Establishment, a worthwhile history of the industry from ENIAC through the mainframe era.)
What language do you code in? Let me know, by leaving a comment below or e-mailing me directly at [email protected].
Like this blog? Subscribe to its RSS feed, here.
For a mobile experience, follow my daily observations on Twitter.
Check out my tech videos on this YouTube channel.
Alex Wolfe is editor-in-chief of InformationWeek.com.