I am the developer of some family tree software (written in C++ and Qt). I had no problems until one of my customers mailed me a bug report. The problem is that he has two children with his own daughter, and he can’t use my software because of errors.
Those errors are the result of my various assertions and invariants about the family graph being processed (for example, after walking a cycle, the program states that X can’t be both father and grandfather of Y).
How can I resolve those errors without removing all data assertions?
While browsing a Groovy/Grails oriented website recently, I came across this article which I felt obligated to share with everyone here at Software @ UNH. The title of the article is You’re a Bad Programmer. Embrace It..
How many developers think they’re good programmers? We’re not. We’re all fairly bad at what we do. We can’t remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we’ve spent years, in some cases decades, learning? We can’t even type the syntax properly, so we have compilers that check and correct it for us.
Don’t even get me started on the correctness of the logic in the code… I’m looking at a chart that shows failure rates for software projects. “Small” projects (about a year for 8 people) have a 46% success rate. That’s almost half. Any longer project just plummets down to a 2% rate for projects costing 10 million or more. In other words, our projects nearly always fail.
If you have a hankering to learn a new language, there’s always Txr. From the Freshmeat description:
Txr is a baroque and painfully hard to use language inspired by, among others, the idea of reversing “here document” generation into “here template” extraction. Since its inception in September 2009, it has grown hair, such as functions that aren’t really like normal functions, and try/catch/finally exception handling. If a complicated Txr query fails on your sample input, just give up. Don’t even think about trying to understand the debug trace output, and the mailing list is likely to be of little help, since pretty much only the author reads it. It is recommended for those who are faced with some simple, boring little problem that is dire need of compounding.
If only all software package descriptions were so honest.
Goes Straight to Hell. (Illustrated.) Arguably safe for work, if your work involves web design. At least you can claim it’s work-related, if anyone asks. But try not to laugh too hard.
Yet another website about programming is Software Engineering Tips, written by an anonymous (as near as I can tell) genius. It’s full of opinions, wisdom, and humor, and may make you laugh, squirm uncomfortably, nod your head in vigorous agreement, or punch the screen. Or all four of those things in some combination.