Taking Responsibility for Software “Bugs”

TwitterGoogle+FacebookLinkedInPinterestTumblrStumbleUponRedditShare This

Alvin Bryan

Alvin Bryan is a freelance writer and online privacy enthusiast enthusiast currently contributing quality tips and troubleshooting on personal VPN services, and online privacy and security news. You can also find him on Google +.

David Thielen, founder of Windward Studios, has talked about software bugs for years. So have other tech geniuses. But Thielen shares an alternative view that bugs don’t just happen. Bugs are major programming mistakes that could be avoided if programmers would just check their work.

No More Software Bugs

Thielen Software BugsThielen has been advocating careful programming for 25 years. Yet it seems that programmers will not do this one little thing. But making the change would mean a radical decrease in the number of software bugs. It will also mean less devastating consequences when the occasional mistake does happen. This is great for users of the software who depend on it to keep data secure and private. But it’s also great for companies because it means they can release products earlier and not have to deal with so many issues.

First of all, we should stop using the term software bugs, according to Thielen. When we use the word bugs, it makes us think that something went wrong because outside influence. The truth is that the problem is internal, a mistake made by the programmer. Nothing the user did caused it, and no user who isn’t a programmer can fix it. And it usually takes a long time to fix a “bug” because now someone has to go back in and try to figure out what the heck was done wrong. And when you’re dealing with code, it’s like looking for a needle in a haystack. Even if you were the original programmer, it’s a huge pain to do.

Software BugsSo why not just be more careful and stop making mistakes? This approach seems totally legit. And more importantly, Thielen says, programmers need to recognize that these are mistakes, not bugs. This makes them stop hoping that no one will find any and start making an attitude adjustment. When they are prepared for people to find mistakes and prepared to have to fix them, it makes a huge difference. They will be more careful to begin with, and work at fixing them more heartily. Plus, they will, rather, hope that all of the “bugs” are found so that they can be fixed sooner than later. They will recognize their responsibility and own up to their mistakes.

4 thoughts on “Taking Responsibility for Software “Bugs”

  1. I never thought about bugs being so much related to carelessness. I don’t code so I don’t know how hard it is but if this guy says so then I really wonder why there aren’t more careful to begin with.

  2. I myself do code a bit and I can say that it’s a real pain to go back and clean things up. This is part of the problem because most would just put a patch on it and call it a day, as long as it works. Really not a good idea for security software though because it leaves holes for hackers to find and more work again later.

  3. I agree because it really would be much better to do it right the first time. Isnt that true for everything anyway? But coding can be so tedious that at some point you just want to get a working version done and deal with bugs later, if anyone finds any. Not very honorable I know. Also sometimes the guys up top don’t really know what they want then later you have to change things because they want different features. And you can’t start from scratch because it means more delays. So you got spaghetti and bugs are only a matter of time.

    • I think this is exactly what Thielen was driving at. I’m sure he understands the whole dynamic, but has to say what is painful to say – ultimately it is a choice of whether to produce quality code or allow “bugs” to happen regardless of the obvious consequences for security.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>