Automated testing is one of the most important parts of software development, and yet until now, we haven’t mentioned it. Testing a piece of software relies on a thorough understanding of the tools you are using, and designing tests can be far more difficult (and enjoyable) than writing the code itself.

— Head First Rails pg 407

Despite Rails effort in making testing easy the Head First Rails book ignores testing altogether until a slight mention on one of the very last pages of the book. I perused the index hoping I was wrong, but the author spells out that it was a deliberate decision.

I have a lot of respect for the Head First books as a great way to jump in and learn something new. I’ve posted before about how impressed I was when Head First Software Development went into depth on Agile and testing. Here I’m just saddened by the decision. Even a short appendix with a few examples might have sufficed if not examples throughout or a dedicated chapter. All the other Rails books I’ve come across at least devote some time to the testing conversation.

Say No. This is your second most powerful tool. Whether you’re a manager, considering management, or just here for the Rands, I want you to pick the hardest problem on your plate. The one that is waking you up at 4am. I want you to decide and to say out loud:

“No.”

You’re not going to do that thing. QA can’t test it. Engineering won’t finish it. If we attempt to do it, we will fail and we don’t fail, so the answer is “No”.

— Rands

Rands spells out the importance of saying no. A critical point in plotting your strategy is saying no. After a good round of brainstorming you’re itching to start 5 different major initiatives. Maybe customers want to get started on new features as you’re still trying to launch weeks away from launching the baseline app.

The tough answer as a manager is often no. Agreeing to a impossible deadline and attempting to toss quality aside is bad for your team and bad for the organization. Saying no is the right thing here.

My best experience with source control trees have been in shops that didn’t have them to start with. At that point you have a blank slate and you can do a reasonable job of organization. The ones where they used to have VSS and migrated into CVS and then Clearcase are generally just a mess. You have a lot of historical junk that’s poorly organized.

My current situation is messy:

• The first source control system was VSS. Unfortunately a few projects are still stored there as there was not a wholesale migration.
• Perforce was brought in next, but largely the organization was organic instead of organized. Despite being a commercial solution I’ve actually found Perforce to be a reasonable source control system.
• Despite being deployed on a UNIX box many of the directories including top level directories include spaces. This causes a nasty issue with the Perforce plugin for Hudson where you can’t use the plugin because it refuses to escape a directory with spaces correctly.

Our eventual solution is to migrate to subversion or maybe even git. Unfortunately we have to live with the current pain for now.

After one of those weeks where emergency after emergency cropped up between meetings I let my inbox get out of hand and left emails sitting in them as todo items. I’ve been a GTD follower for about 5 years now and I start to really feel out of control when my inbox is piling up. I know I’m re-reading the same email for the third time, but I fall into a hypnotic state.

Yesterday, I made a point after getting in early to really drill my inbox down move actions onto my lists. 171 emails later I had cleared everything dating back to 3 weeks ago. Freed of the mental distress of an overloaded inbox I’ve gotten more strategic items done in the last two days then I did all of last week. On top of that I’ve pushed along a wealth of issues that had been idling for weeks.

And the best part is I’m back to quick email sweeps 3 times a day to keep my inbox clean. If you’re one of those people who live in a 10,000+ inbox you might want to go back and read Merlin Mann’s articles on Inbox Zero.

Some recent signs of continuous testing coming to Java land:

• Grails 1.1 features 9 new features including #9 Continuous Testing.
• Kent Beck is developing JUnit Max an Eclipse plug-in that runs tests in the background optimizing for the tests that are most likely to break.

Autotest was a joy to use when I got to spend more time playing with Rails. Maybe I won’t have to miss it that much longer.