Viking laws for tech teams, part 4: keep your weapons in good condition

This post is part of the "Viking laws for tech teams" series.

As much as I regret it, software engineering doesn't actually involve two-handed swords and battle axes... although managing teams sometimes does :) Still, every trade had its tools and no matter if you're chopping heads off or squashing bugs, proper tools are a key element in achieving high productivity.

First things first: the workstation. Yes, you need to give your team nice machines to work on. It's quite likely that your guys have fancy hardware at home and they won't settle for a 5-year old setup in the office. If nothing else, see this as a (de)motivation factor. Truth be told, modern software development environments *are* resource hogs and a slow workstation is a silent productivity killer (build time, freezes, inability to debug properly, etc).  Dual screens are super useful too. Throw in a fancy keyboard or mouse, too. Whatever keeps your guys working on their code is a good investment. And no, it's not going to cost a lot of money: slow teams & delayed projects do.

What about team tools? Version control system, continuous integration, unit test framework, ticketing system, wiki, etc: absolutely mandatory from day 1. Yes, even if you're a one-man team. If hosted solutions are your thing, then Sourceforge or Github are just a few clicks away. One way or the other, there's just no excuse for not setting things up properly. 'nuff said.

Next, get the best debugging / profiling tools possible and spend some time learning them (yes, you need to go beyond debugging HelloWorld). Make sure that everybody in the team is proficient BEFORE a real emergency arises. The last thing you want is having to read tutorials and installation documentation while your production systems are on fire, with management asking for progress reports every 30 minutes... You should also consider 3rd-party tools, whether Open Source or commercial: your IDE debugger will only take you so far, especially if you work on complex, dynamic systems (web servers, databases, etc).

Remember that the strongest castle will easily fall if no sentries man its perimeter. Real-time monitoring is your first line of defense, so you'd better set up the right probes in your code and make sure alerts are actually sent when something goes wrong. If you think error logs or e-mails are enough, you'll sure get plenty of opportunity to read them when the SHTF: whether you'll find the actual problem or not is a different story. You should invest a lot of time watching your systems and understanding their dynamics. It's particularly important to study how they fail (silently vs loudly, progressively vs abruptly, early symptoms, etc). You should definitely consider breaking them in a controlled way to confirm your observations and then write short documentation on how to detect and repair the most common issues.

A couple more things:

1. tools are not enough, you need the right organization and the right tactics. This will be covered in a further post :)
2. I hear some of you saying: "it's all good and true, but in my company, workstations are renewed every 5 years at best, we have 14-inch CRT screens, it's company policy to use CVS and management won't ever spend a dime on 3rd-party tools". My answer is: "these guys have zero respect for your work. Get the fuck out & find new battle comrades". Yes, it's THAT simple. Do it or stop whining.

Bottom line: one day or the other, barbarians WILL show up at the gates, preferably when you least expect it. If you have neither beefed up the armory nor trained hard enough, you will be overrun and Odin's crows will feast over your carcass. If you've done both, THEIR heads will decorate your walls and warn the next assaillants that your team is not to be fucked with.

Your choice.

Please share your comments or anecdotes. See you next time.