More Than Coding Errors Behind Bad Software

An anonymous reader writes "SANS' just-released list of the Top 15 most dangerous programming errors obscures the real problem with software development today, argues InfoWeek's Alex Wolfe. In More Than Coding Mistakes At Fault In Bad Software, he lays the blame on PC developers (read: Microsoft) who kicked the time-honored waterfall model to the curb and replaced it not with object-oriented or agile development but with a 'modus operandi of cramming in as many features as possible, and then fixing problems in beta.' He argues that youthful programmers don't know about error-catching and lack a sense of history, suggesting they read Fred Brooks' 'The Mythical Man-Month,' and Gerald Weinberg's 'The Psychology of Computer Programming.'"

Comments

Perfection Has a Price

[alain94040]

The most common errors: SQL injection, command injection, cleartext transmission of Sensitive Information, etc.

People make mistakes. Software needs to ship, preferably yesterday.

How much would it cost to have perfect software? I happen to have worked in an industry that requires perfect coding. So I can imagine what it would look like if Microsoft tried it.

The debugger would cost half a million dollar per seat (gdb is free). There would be an entire industry dedicated to analyzing your source code and doing all kinds of proofs, coverage, what-if analysis and other stuff that require Ph.Ds to understand the results.

The industry I'm referring to is the chip industry. Hardware designers code pretty much like software developers (except the languages they use are massively parallel, but apart from that, they use the same basic constructs). Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.

It's just not practical. Let the NSA order special versions of Office that cost 10 times the price and ship three years after the consumer version.

But for me, "good enough" is indeed good enough.

--
FairSoftware.net -- work where geeks are their own boss

Re:Perfection Has a Price

[Opportunist]

The problem is that software doesn't even ship as "good enough" anymore. It's more like "it compiles, ship it".

Your example of hardware, and how it's impossible to patch it, was true to a point for software, too, in the past. Before it became easy to distribute software patches via the internet, companies actually invested a lot more time into testing. Why? Because yes, you could technically patch software, but it was tied to sometimes horrible costs to do just that.

You can actually see a similar trend with the parts of hardware (i.e. BIOSes) that are patchable. Have you ever seen hardware shipped with all BIOS options fully enabled and working? I haven't in the past 2-3 years. More often than not you get a "new" board or controller with the predecessor's BIOS flashed in, and the promise for an update "really soon now".

The easier it is to patch something, the sloppier the original implementation is. You'd see exactly the same with hardware if it wasn't so terribly hard (read: impossible) to rewire that damn printed circuit. I dread the day when they find some way to actually do it. Then the same will apply to hardware that you have today with some OSs: It's not done until it reads "SP1" on the cover.

Re:Perfection Has a Price

[Timothy Brownawell]

I happen to have worked in an industry that requires perfect coding. [...] The industry I'm referring to is the chip industry. [...] Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.

What does "stepping: 9" in /proc/cpuinfo on my home computer mean? What is a f00f, and what happened with the TLB on the early Phenom processors?

Re:Perfection Has a Price

[Schuthrax]

You'd run your program and it was ready in a second, you'd exit and it left no trace. Crashes were virtually unheard of.

And all without managed memory, automatic garbage collection, etc., imagine that! Seriously, I see so many devs (and M$, who has a product to sell) insisting that all that junk is what will save us. What they're doing is attempting to create a Fisher Price dev environment where you don't have to think anymore because they've done it all for you. What's going to happen to this world when GenC# programmers replace the old guard and they don't have the least clue about what is going on inside the computer that makes the magic happen?

When I was breaking in

[PingXao]

In the early '80s there were no "older" programmers unless you were talking mainframe data processing. On microprocessor CPU systems the average age was low, as I recall. Back then we didn't blame poor software on "youthful programmers". We blamed it on idiots who didn't know what they were doing. I think it's safe to say that much hasn't changed.

Re:When I was breaking in

[Skapare]

This is true with any group. There are geniuses and idiots in all groups. The problems exist because once the supply of geniuses have been exhausted, businesses tap into the idiots. And this is made worse when employers want to limit pay across the board based on what the idiots were accepting. Now they are going overseas to tap into cheaper geniuses, which are now running out, and in the mean time, lots of local geniuses have moved on to some other career path because they didn't want to live at the economic level of an idiot.

Re:When I was breaking in

[Surt]

Do you care whether they write a loop or return (n*n+1)/2? (where n=100 in this case?)

(curious whether you are looking for the person who knows the clever solution, or the guy who can write a basic loop).

Re:When I was breaking in

[Opportunist]

What you describe is a wannabe-genius. A showoff. Not a genius.

The code that makes me mutter "that's pure genius" is usually not the kind of code you can't understand or is winded, twisted and a worthy entry for the obfuscated C-Code contest. It's usually code that is brilliantly simple yet very functional, fast and easy to understand.

Genius code isn't the code that takes a year to read and a decade to understand. It's the code that makes you wonder why you didn't come up with it because it, well, looks so simple that it's pure genius. A good example of "pure genius" code is the square root function that relies on the quirks of the IEEE754 format. Works only on 32bit little endian, but there it works and is fast.

Pure genius code doesn't mean it has to be complicated, quite the opposite. "Pure genius" is what it mostly attributed to finding new ways to do something in a better way. Not making it overly complicated to look like you did something great.

Waterfall

[Brandybuck]

The waterfall method is still the best development model. Uou have to analyze, then plan, then code, then test, then maintain. The steps need to be in order and you can't skip any of them. Unfortunately waterfall doesn't fit into the real world of software development because you can't freeze your requirements for so long a time. But cyclic models are a good second place, because they are essentially iterated waterfall models. When you boil all the trendy stuff out of Agile, you're basically left with a generic iterated waterfall, which is why it works. The trendy crap is just so you can sell the idea to management.

Re:Waterfall

[Timothy Brownawell]

The waterfall method is still the best development model. [...] Unfortunately waterfall doesn't fit into the real world

WTF? Not working in the real world makes it a crap model.

When you boil all the trendy stuff out of Agile, you're basically left with a generic iterated waterfall, which is[...]

...not a waterfall.

Re:Waterfall

[radish]

The waterfall is broken, seriously. I'm paraphrasing from an excellent talk I attended a while back, but here goes.

For a typical waterfall you're doing roughly these steps: Requirements Analysis, Design, Implementation, Testing, Maintenance. So let's start at the beginning...requirements. So off you go notebook in hand to get some requirements. When are you done? How do you know you got them all? Hint: you will never have them all, and they will keep changing. But you have to stop at some point so you can move onto design, so when do we stop? Typically it's when we get to the end of the week/month/year allocated on the project plan. Awesome. Maybe we've got 50% of the reqs done, maybe not. It'll be a long time until we find out for sure...

Next up - Design! Woot, this bit is fun. So we crank up Rose or whatever and get to work. But when do we stop? Well again, that's tough. Because I don't know about you but I can design forever, getting better and better, more and more modular, more and more generic, until the whole thing has flipped itself inside out. So we stop when it's "good enough" - according to who? Or more likely, it's now 1 week to delivery and no-one's written any code yet so we better stop designing!

Implementation time. Well at least this time we know when we're done! We're up against it time wise though, because we did such a good job on Reqs & Design. Let's pull some all nighters and get stuff churned out pronto, who cares how good it is, no time for that now. That lovely, expensive design gets pushed aside.

No time to test...gotta hit the release date.

Sure this isn't the waterfall model as published in the text books, but it's how it works (fails) in real life. And the text books specifically don't say how to fix the problems inherent in the first two stages. What to do instead? Small, incremental feature based development. Gather requirements, assign costs to them, ask the sponsors to pick a few, implement & test the chosen features, repeat until out of time or money.

Users are to blame

[Chris_Jefferson]

The sad truth is, given the choice between a well-written, stable and fast application with a tiny set of features and a giant slow buggy program with every feature under the sun, too many users choose the second.

If people refused to use and pay for buggy applications, they would either get fixed or die off.

Complete BS?

[DoofusOfDeath]

For the life I me, I can't figure out what the choice of {waterfall vs. cyclic} has to do with {writing code that checks for error return codes vs. not}.

Waterfall vs. cyclic development is mostly about how you discover requirements, including what features you want to include. It also lets you pipeline the writing of software tests, rather than waiting until the end and doing it big-bang approach. Whether or not you're sloppy about checking return codes, etc., is a completely separate issue.

Despite the author's protests to the contrary, he really is mostly complaining incoherently about the way whipper-snappers approach software development these days.

It's economics, too...

[gillbates]

As long as:

• Consumers buy software based on flashy graphics and bullet lists of features, without regard for quality...
• Companies insist on paying the lowest wages possible to programmers...
• Programmers are rewarded for shipping code, rather than its quality...

You will have buggy, insecure software.

Fast. Cheap. Good. Pick any two.

The market has spoken, and said that they would rather have the familiar and flashy than secure and stable. Microsoft fills this niche. There are other niches, such as the Stable and Secure Computer market, and they're owned by the mainframe and UNIX vendors. But these aren't as visible as the PC market, because they need not advertise as much; their reputation precedes them. But they are just as important, if not moreso, than the consumer market.

Re:Its all true

[Cornflake917]

I think refusing to hire someone solely because of their age is naive. Is there some magical event at the age of 30 that bestows knowledge of linkers to the aging programmer? Give me a break. You are making bad assumptions. Your first bad assumption is that just because of your anecdotal experience dealing with one individual, that all schools no longer teach anything about linkers. Your second bad assumption is that even if that was true, no programmer would learn that information on their own, as if no one is generally interested in learning comp sci any more outside of the classroom.

Question

[coryking]

When you were working on those punch cards, using your green screen console (kids these days with color monitors and mice), what were you doing?

Did you ever transcode video and then upload it to some website called Youtube on "the internet"? Did you then play it back in a "web browser" that reads a document format that your grandma could probably learn? Did your mainframe even have "ethernet"? Or is that some modern fad that us kids use but will probably pass and we'll all go back to "real" computers with punch cards.

Did you ever have to contend with botnets, spyware or any of that? And dont say "if we used The Right Way Like When I Was Your Age, we wouldn't have those things because software would be Designed Properly". because if we used "The Right Way" like you, software would take so long to develop and cost so much that we wouldn't even have the fancy systems that even make malware possible.

Old timers crack me up. Ones that are skeptical of object oriented programming. Ones who think you can waterfall a huge project. I'd like just one of them to run a startup and waterfall Version 1.0 of their web-app (which, they wouldn't because the web is a fad, unlike their punch cards).

Sorry to be harsh, but get with the times. Computing these days is vastly more complex then back in the "good old days". Your 386 couldn't even play an mp3 without pegging the CPU, let alone a flash video containing one.

I've seen their workflow and how fast it works for them and I can see if they "modernized" it would cripple their productivity.

Until they try to bring in new-hires. How long does it take to train somebody who is used to modern office programs to use a DOS program like wordperfect? You think they'll ever get as proficient when what they see isn't what they get (a fad, I bet, right?)

Again, sorry to sound so harsh. You guys crack me up. Dont worry though, soon enough we'll see the errors in our ways and go back to time honored methods like waterfall. We'll abandon "scripting languages" like Ruby or C and use assembler like god intends.

Sheesh.

There is no shortage of good coders or IT people

[jeko]

I bought three Mercedes. Two of them got repossessed. Now, the dealers won't finance me when I go to buy another. Clearly, there is a shortage of Mercedes.

Look at your story. You had three programmers. Two quit (Yeah, I know, it wasn't because they were unhappy. Look, no one wants to be known as a malcontent or difficult. They lied to you.) Now, you can't get anyone in to interview who knows what they're doing.

You think maybe it's possible that your company's reputation precedes it? I know of half a dozen places in my town that nobody in their right mind would agree to work for.

Show me a man who says he can't find anyone to hire, and I'll show you a man nobody wants to work for.

Take that same man, triple the wages he's offering and wire a pacifier into his mouth and the ghosts of Ada Lovelace and Alan Turing will fight for the interview.

The issue is a lack of local coding standards.

[Richard Steiner]

If you perform certain types of validation on a routine basis, write a set of common routines to do the work, and reuse them over and over again. Standardize your code. Define standard buffer names, sizes and buffer attributes, and make sure that anyone working on that code is acutely aware of the standards which are already in place.

Reject code that doesn't follow the standard. Even if it works otherwise.

Modular coding isn't rocket science, and one can be very structured and modular in any language. No OO needed. We had an extensive library of common routines, common buffers, etc. back when I wrote Fortran 66 and 77 code at my last major place of employment, and we have the exact same thing here on both the C and Fortran sides of life.