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.

Audits are easy to pass. You have a documented process. You have a pile of documentation that shows that you followed the process. An auditor independently validates the documentation. Much like running your suite of tests on a CI server.

In an average IT shop you may even have audits of your software process. Recently I used our CI server to help streamline the audit process. We actually had a formal document for unit test plans and unit test results. I value the idea behind the documents, but I don’t know that filling out the Word template was going to accomplish much beyond passing an audit finding.

Upon a request I simply sent a URL over to the PM on the project. It just pointed to that particular project’s JUnit test case reports. That URL should be constant through the life of the project. Now you have documented real time evidence that unit tests are being written and executed. Your CI server can make life easier for auditors.