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.

Building a solid bench involves years of preparation with no immediate reward. Hiring a team from scratch is a beautiful dream. I got to do it once at a startup before I had much experience as a manager. In many ways I’d love to re-live that experience, but I haven’t worked at a startup in almost 10 years now.

If you’re not at a fast expanding startup you’re hiring opportunities are going to be an uncommon occurrence. Unfortunately they’re probably the most critical aspect of your job. Nothing is more important than building a team with the right people. Management success is all about people.

Building your bench is the process of making sure when you do get the rare open req that you have some great people just a phone call or email away.

I’m still working on techniques here and my networking skills need to grow, but this has been the tips I’ve picked up over the years:

1. Keep in touch with your high performers from previous jobs. Obvious, but this means you have to make a habit of making the occasional phone call or email and making sure you know how there career and life are going.
2. Stay in the same area. I’ve violated this one before and it can hurt. I’ve worked for some great companies in the Bay area and in Las Vegas and had a good network of people in both locations. When I moved up to Sacramento 8 years ago I still kept in touch with many of them, but a remote bench just isn’t effective compared to having a local one.
3. Attend conferences, local user groups, and meetups. Passionate software developers show up at user groups and meetups. The local java and ruby user groups have been a great source of motivated talent as well as a nice social gathering. And yes this means when the group goes out after the presentation you should tag along.
4. Keep old resumes and interview notes. I’m in a medium size city, but there are only so many software developers in a town this size. You will run into people again. Often they’ll be developers who you thought had potential 7 years ago, but were too inexperienced to bring on board. It always feels like deja-vu, but it’s happened to me more than once.
5. When opportunities arise be frank about the minuses. Good recruiters know this well. You’re dealing with a long term relationship so you don’t want to get someone excited or bring them into a situation that is too risky or just wrong for them. They need to know if the company is generally slow paced, doesn’t have that many benefits, or they’ll be working with a largely junior team that will need a lot of mentoring. Selling the upside is fine, but give them the downsides.
6. Don’t get frustrated if some of your bench turns you down. Maybe the opportunity was great, but someone’s comfort level in a downturn is to stay with their current company. The situation may be very different a few years later.

Not to long ago one of my developers came across a little mockup tool called Balsamiq and then I saw a post from Clark Ching who checked it out as well. I love the sketchy look and feel and rendering a quick mockup form was good fun. We’ll probably try it out on a future project and see if we can get some value out of it. Much like the Swing Napkin look and feel the value is from being obvious that this is not to focus on look and feel, but more on the functionality of a web site.

Denis over at One Brike At a Time recently expressed frustration at having to use low trust practices:

It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write decent unit tests.

The frustrations are real. Teams are often at many different levels of skill and experience. Even minimal unit testing is not a common practice in many shops. You can still find developers who look surprised when you ask where their code is checked in.

Lower trust practices can be a bridge:

• Source control is a given. Developers who check in bad code you might force you to lock things down for now. Continuous integration is a way to grow out of this. If all of your projects are being built with any change, you can quickly discover if someone’s injected some issues. This might mean setting up notifications for even successful builds for non-active projects.
• Code reviews don’t have to be a negative. I’ve used them and still use them more for mentoring than as an audit of bad code. Code reviews are easy to get wrong, but used safely they can improve the code base and improve your coders through sharing. And I always leave the easy out–no code reviews if you’re pair programming. *

After about 45 minutes of frustration trying to work through some maven exercises in the Sonatype book I kept arriving at the following message:

I had the sample code downloaded and got the same error, so I investigated possibly not having access to the maven repositories. I’m on my in-laws network, possibly there’s something being blocked. I tried other mirrors without any success. Finally I just deleted the local maven repository and re-ran

and everything just worked. I had forgotten how finicky the local repository can be.