Your code is wrong.

Or it's bad, or it won't work as intended. I'm not sure that's the viewpoint I'd like to take when I first start working on a project, but that's what Nathan Marz told the attendees at the NoSQL2013 conference recently. He says that our code should be treated as something that might or might not work, and we should embrace the idea that the code can be wrong. It's not intended to disparage developers or paint too bleak a picture of our skills, but to just be realistic in the sense that all projects have problems and software isn't perfectly built at the first compile.

I think most of us do realize that our software also might not work as intended. Even simple projects can have bugs and holes that we'll find when edge cases are introduced or the software is used in a way we didn't expect. At least I hope it's just unanticipated, edge cases and not general cases for most of us. If an application doesn't work for the cases we've designed it for, then we need to work on our coding skills.

We know that building software is hard. We know that outside of a narrow domain for which we've often designed our software, it might not work as intended. Most of us expect to find bugs or problems in our software, and are mentally prepare to patch and enhance our work as needed. It's almost inevitable, and even occurs when you design your own software, to do that one thing you need done. You'll still maintain (meaning patch or enhance) the software over time.

I hope that's not too gloomy a view of software.