In the last three companies in which I’ve held position, I’ve not once seen any consistency across the development team. Each time I’ve started a new position, I came with the presumption that the “team” was on track and had their stuff together and I was always ready to learn something new. Nope. Teams have been disorganized, fragmented and mismanaged. Apparently this is a common theme. I’ve actually only seen one team (small, five people) who actually had their stuff together, but that was because they were employing a radical technique (which I found intriguing btw).

My current position is no different. It’s like the wild west and everyone has their own homemade guns and law books. Thankfully there is awareness by upper management that something had to be done to rein in on these cowboys. So when I came on, I proposed standards and best practices policies and training. They were all for it and I had my management buy-in!

Development is like driving. Everyone has their own style of driving; some drive fast and some drive slow. Some don’t use their friggin’ blinkers and some do. But, as drivers, we all have a set of rules we have to follow that were set forth by an authority. When you get in your car and head to work, you know that you have to drive on a certain side of the road. You know that you have to stop at a stop sign and speed up when the light turns yellow (just kidding). We all follow these rules and it makes for a consistent driving experience that allows everyone to arrive at their destination safely and consistently.

When you go to another city/state/province/whatever, you don’t have to relearn any rules. You know that you have to still drive on a specific side of the road. As developers, the on-boarding process can be excruciating trying to learn how other developers work, think and write code. Usually it’s painful because you either have to lower your standards to work with less skilled developers or you realize that you’ve been writing junk this whole time.

What I’ve proposed for the dev teams here is a set of standards that apply to a wide range of topics. Some of them are industry best practices or at least de facto best practices. Some common sense, and some are just the way I think would be best for this environment. After a three hour training session, the material was actually well received and it opened some eyes. Some developers were excited to be learning and some were the equivalent of grumpy old men who refuse to learn how to work an iPod. But it doesn’t matter. Everyone had a chance to give input and shape the way things are done.

Because of the acceptance of the material by this diverse team and the realization that so many other dev teams suffer from the same ailments, I’m going to be doing a blog series on the material I created for standards and best practices. I’ll cover topics ranging from code, check-in policies and how to divide the team up into specific roles.

I’m probably going to be ridiculed on somethings, but that’s ok because I’m always willing to learn. You can choose to accept the material or ignore it. But at least it’s out there for teams to get a hold of. It’s working here so it can work somewhere else.

If your team is super awesome, I’d love to talk with you/them and get input and insight to how things are ran there. Otherwise, use the content in the forth coming posts as a template.

Advertisements