Michael Mahemoff on Error Messages We’d Rather Not See.
I had a brief conversation on why blog at all with an old friend of mine (back from our days at the university), so here’s a great presentation on corporate blogging by Loic le Meur on this very topic.
Sam Gentile provides a great write-up on the Test-Driven-Development (TDD) process.
Here’s Joel Spolskys Recommended Reading List. A great list.
Here are a few books which yours truly would add to a recommended reading list (in descending order of importance):
Refactoring: Improving the Design of Existing Code – Martin Fowler
Extreme Programming Installed – Ron Jeffries et. al.
Test Driven Development: By Example – Kent Beck
Working Effectively with Legacy Code – Michael Feathers
Agile Software Development, Principles, Patterns, and Practices – Robert C. Martin
Extreme Programming Explained – 1st edition – Kent Beck
Code Complete, Second Edition – Steve McConnell
Debugging the Development Process – Steve Maguire
Thinking in C++, Volume 1: Introduction to Standard C++ (2nd Edition) – Bruce Eckel
If you like Dilbert, you must read Scott Adams blog: The Dilbert Blog.
Having read the book on my recent vacation in Turkey, I must confess that I’m not happy with the
2nd edition of “eXtreme programming explained” by Kent Beck and Cynthia Andres.
Although it adds a lot of useful, practical insight to the ideas presented in the 1st edition, it lacks the precision, unambiguousness and purity of its predecessor.
If the book was meant as a definition and reference for XP, it failed. If it was meant as a collection of anecdotes, war stories and valuable lessons learned from applying XP in the field, then it’s a great book.
In a reference book, rules have to stated clearly, precisely, maybe even provocatively. After all, the rules are the basis of any methodology.
Applying these rules or specs in practice is a totally different stories. It requires taking into account the specific culture of a company, the boundary conditions of a given project, code base, engineering team etc. That’s why rules have to be bend and to be adjusted to a given situation. After all, they’re just rules.
But this doesn’t mean that you should dilute the specification.
Signal vs. Noise: “It is trivial to estimate a new feature as trivial.”
Here’s a site which features great bug reports (mostly on topics related to MacOS X / MS Office X). These bug reports are in depth, with lots of screen-shots, suggestions on how things could be improved etc. In fact, I would be glad if the bug reports we receive would be half as good as these posted on betalogue.com.
However (and you knew this would come, don’t you), there’s one major caveat. The author sometimes uses judgmental language to comment on these bugs and the software developers responsible for these bugs.
Don’t do that. Don’t use judgmental or even insulting language.
Refrain from using phrases like “I wonder what these guys have been thinking….” or “It’s obvious that XYZ doesn’t think about…” or “Again, XYZ proves that they don’t pay enough attention to….”. Don’t speculate about issues with the developers code.
State what’s wrong. State what you expect. State how this bug affects you. Provide sample documents/screen shots – anything which may help to resolve the bug.
If you’re really pissed, still use neutral language. If you’re not pissed, but slightly annoyed, use upbeat language. You will be surprised how much this will help a constructive discussion about the bug and how much more attention is paid to your report.