Programmers make mistakes, we all know that. But some are worse than others. Say you hardcode a file name, and you make a typo in the name. When you do your own testing before passing it off to others, you'll discover the typo because it keeps the application from working. But if you fix the typo, there's a good chance no-one will notice the other mistake - hardcoding the file name - for a very long time. In fact, if the file never moves, under some circumstances you could claim it isn't even a mistake to hardcode the name. But if the file does move, hardcoding the name is a much worse mistake because it causes a bug that a customer discovers - and that is always bad. Writing your data access code so it brings back the wrong records (say, forgetting to filter by date) will show up the minute you hit F5, but writing your data access code so it's vulnerable to SQL injection is far worse - you'll think the application works, but when you put it into production you'll have opened a large hole into your database for bad guys.

The SANS Institute has created a list of what they consider to be the 25 most important programming errors of all time. There's a lot not to like in this list, to be honest. First, it's not so much a list of errors (John typed this line of code in that application) as it is kinds or categories of errors. Second, a lot of them look like the same error over and over (trusting stuff that people give you as input, for example). Third, the post spends pages and pages on credits, acknowledgements, explaining why they are important, predicting how the world will be made better by this list existing, and so on before finally getting to the errors. Fourth, the names are flat-out weird in a lot of cases. But with those disclaimers in mind, I still think the post is worth reading and the errors are worth thinking about. Here are the 25:

• Improper Input Validation
• Improper Encoding or Escaping of Output
• Failure to Preserve SQL Query Structure (aka 'SQL Injection')
• Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
• Failure to Preserve OS Command Structure (aka 'OS Command Injection')
• Cleartext Transmission of Sensitive Information
• Cross-Site Request Forgery (CSRF)
• Race Condition
• Error Message Information Leak
• Failure to Constrain Operations within the Bounds of a Memory Buffer
• External Control of Critical State Data
• External Control of File Name or Path
• Untrusted Search Path
• Failure to Control Generation of Code (aka 'Code Injection')
• Download of Code Without Integrity Check
• Improper Resource Shutdown or Release
• Improper Initialization
• Incorrect Calculation
• Improper Access Control (Authorization)
• Use of a Broken or Risky Cryptographic Algorithm
• Hard-Coded Password
• Insecure Permission Assignment for Critical Resource
• Use of Insufficiently Random Values
• Execution with Unnecessary Privileges
• Client-Side Enforcement of Server-Side Security

The full details are in the linked post and it won't take more than a few minutes to read the description of each error. Pat yourself on the back, or go do a quick code review so you can say you don't do any of these.

Kate

Being a Microsoft Regional Director has a host of benefits, most of which are intangible and hard to explain to someone who's not experiencing them. The number one benefit, for example, is the other RDs. They're such a smart and fun group, and the connections have helped me personally and professionally. The only drawback to being an RD is that so few people know what it means. They think perhaps we work for Microsoft (nope) or that it's like being an MVP (nope, though many of us are MVPs as well) or that we get paid to do it (nope again.)

Recently Joel Oleson had a crack at it. The phrase "unbiased evangelist" is a little tricky, isn't it? And we're not exactly evangelists either ... Microsoft already has people for that. I would say that we've chosen Microsoft technologies (not always exclusively) for our own reasons (that is, not because someone compensated us directly for choosing them) and we're happy to share our reasoning with others. It's that sharing that gets us the nod to become RDs.

Kate

I've been doing some training lately and of course conference season is on the way, so I'm starting to think once again about the mechanics of talking to audiences. One relatively recent change in audience is the popularity of Twitter. It is starting to create a far more public backchannel, one that even the presenter (or the presenter's colleagues) can read and respond to during the talk.

Private, even secret, backchannels are nothing new. I've been on many a conference call where 5 or 6 of us are on Messenger discussing the call itself (and we probably wouldn't want the speaker to read what we were typing.) I've also been in physical meetings where a small group of people are privately discussing the meeting itself, whether co-ordinating who will say what when, or just aimless snarking and wondering when we can leave.

But a public backchannel, maybe even one you have an obligation to monitor, is a very different beast. Some folks, like Olivia Mitchell on Tamar Weinberg's blog, think it's all-good all-round: better for the audience, the presenter, the world as a whole. Presenters just have to learn new reflexes: when your audience suddenly starts typing and looking at their screens, it doesn't mean you've lost them, just that you're so interesting and the information is so important that they feel the need to share with the world immediately. Ira Basen is not so sure, especially if the tweets are negative and going out in public before the talk has even finished and without asking the presenter any questions.

Different conferences will probably lead to different conventions and habits. I can imagine a lot of tweeting from a keynote where things are being announced or demo'd for the first time. But if I'm doing an hour on C++ 0x features, I can't really see why "OMG Lambdas r AWESOME" can't wait until the talk is over. "Now showing capturing the whole stack by reference" doesn't seem like a likely tweet. I can tell you that I'm not going to have a window open on my screen where I'm following "my channel" and that if you want to ask me a question, it's going to involve speaking aloud, at least for now. That said, it's a good idea to think about the impact of wireless internet in every room and instantly-constructed channels on speaking, on conferences, and on the way we all share information. I think there will be more room-switching early in talks if people learn that someone else is really doing a great job, and attendees may demand more agility in scheduling repeats and extra sessions on topics that were well received. As always, we live in interesting times.

Kate

Ronan Geraghty has an interesting blog, full of topics that interest me, with lots of BizSpark, WPF, Windows 7 and client development content. In a recent entry he explains that getting the Windows Logo on your software product is going to be a lot easier for Windows 7. Instead of submitting your application to a third party for testing, you can test it yourself and get certification without paying someone else.

Why would you want to certify your product and get the Windows Logo? I can think of at least three reasons:

• The certification process may raise your quality bar by imposing some constraints on you that you were planning to skip.
  (Have a clean, reversible installation; Install to the correct folders by default; Support Multi-user sessions; etc.) That may feel like a drawback to some, but for those who wanted to put these features in, the logo program may be a good reason to have them.
• There may be some customers somewhere who are more likely to buy something with the logo on it. There certainly are none who are LESS likely to buy because you took the time to get certified.
• Having a logo'd product gets you a competency in the Partner Program and makes you a Certified Partner, which comes with a suite of benefits you're sure to want.

So making it easier to get the logo is nothing but good news. Follow Ronan's links for more details.

Kate

Michael Feathers put together a list of ten papers that "every programmer should read". I've seen such lists before, and this one is pretty good. I've read Parnas and Cunningham and draw on that background pretty regularly. I'd heard of some of the rest. But the real fun begins in the comments. People suggest additions (Fred Brooks - definitely! Joel Spolsky - why not?) and then other people start saying that reading, especially reading stuff from 20 years ago, just makes you an academic and not useful. Oh my.

I'm useful. I've written a lot of code that's made people's jobs and working lives a lot easier. I've written systems that have transformed companies and enabled them to survive business model changes they thought would sink them. I've rescued projects and made developers better than they were time and time again. And I'm academic. I have a Ph. D. for heavens sake, I teach at a university (no, not full time, one course a year), and when someone uses the word "academic" or "intellectual" as an insult, and I object, they tell me "you're not that kind of academic, not the kind I meant." Well honey, to paraphrase Gloria Steinem, this is what academic looks like. Reading 20 year old white papers and thinking about concepts and theory is one of the things that makes me useful. Folks who just want to get started and type some code and not bother with that high falutin design stuff tend to write bad code.

Grrr. Read the list, maybe read a few of the papers (as the commenters mention, Michael's links are to a site that will charge you to read them, but if you have the author and the title your favourite search engine will undoubtedly help you find free copies lying around on the web) and think a little about why it would be an insult to say that someone cares about history and theory.

Kate

Steve McConnell has a training company, Construx, that is not like other training companies, mostly because Steve is not like other developers. As it says on his web site:

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His first two books won Software Development magazine's Jolt Excellence award for best programming books of their years.

Steve has worked in the desktop software industry since 1984 and has expertise in rapid development methodologies, project estimation, software construction practices, and third-party contract management. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds. Steve was Editor in Chief of IEEE Software magazine from 1998-2002.

There are very few authors who have multiple books on my bookshelf that I paid for. Steve is in rare company there. And the courses they offer? We're not talking "Introduction to Silverlight" or "A First Look At Sharepoint" here. This stuff is more university-like: concepts, theory, the big picture. Some upcoming titles:

• Object-Oriented Requirements Analysis and Design Using the UML
• Professional Tester Boot Camp
• Enterprise Agile: Planning, Managing and Scaling Agile Projects Using Scrum
• Requirements Boot Camp
• Software Estimation in Depth

These are the kinds of courses that change the kind of developer you are, not just teach some new syntax or tool. And they cost thousands of dollars. But Steve has decided that fully one quarter of the seats in each class will now be available for free to people who have been laid off. If you can get to Bellevue WA, you should arrange to take one of these courses. No question about it.

Kate

Here's a list of ways to be a superstar at work, from GL Hoffman. It applies equally to a 19 year old close to me who's starting her first full time job, or to developers who want to work for me. The examples in the article are aimed at a 20-something working in an office full of older people, in a vaguely technical capacity, and is kinda Web 2.0 ish, but the principles are far broader than that. My two favourites: See Work and On Time. But read them all.

Kate

No, I'm not speaking metaphorically. Apparently in this day and age, on this continent, people are being held against their will, beaten and abused, and forced to work for little or no pay. There's no evidence of an actual slave trade, with people sold from one owner to another, or of babies being born into slavery, but nonetheless there are North American slaves today. Perhaps it's no surprise that the task they are set to, harvesting crops in the warmest parts of the USA, is what most of us have in our heads when we think about long-ago slavery on this continent.

This well researched article in Gourmet, and the articles to which it links, lay it all out. There is no dispute that at least some agricultural workers were in fact enslaved. The only issue is whether it's really common or an isolated incident. Here's a quote:

But when asked if it is reasonable to assume that an American who has eaten a fresh tomato from a grocery store or food-service company during the winter has eaten fruit picked by the hand of a slave, Molloy said, “It is not an assumption. It is a fact.”

Hm. Another reason to eat locally and seasonally. I do realize that our insistence on the lowest price for everything is one of the pressures that make abuses like this seem a reasonable course to some people. The article concludes with this suggestion if you, like me, like to buy tomatoes in the winter:

... take advantage of the fact that fruits and vegetables must be labeled with their country of origin. Most of the fresh tomatoes in supermarkets during winter months come from Florida, where labor conditions are dismal for field workers, or from Mexico, where they are worse, according to a CIW spokesman. One option during these months is to buy locally produced hydroponic greenhouse tomatoes, including cluster tomatoes still attached to the vine. Greenhouse tomatoes are also imported from Mexico, however, so check signage or consult the little stickers often seen on the fruits themselves to determine their source.

Kate