Back in Y2K, Joel Spolsky posted The Joel Test: 12 Steps to Better Code. After reading it for the millionth time, I still think it's a great list that can be used to quickly judge a software organization. Even better, the list can be used for gap analysis in looking for ways to improve.
I wanted a similar list for individual developers and the closest I found was Read Write Web's Top 10 Traits of a Rockstar Software Engineer. Their list is great for identifying rock star programmers, but it doesn't really lend itself to coaching good programmers into being great developers. To fill the gap, I decided to look for ways in which a developer can help an organization improve their Joel Test score and get more value out of what they're doing.
The Joel Test:
1. Do you use source control?
The Big Swinging Developer Test:
1. Can you teach developers to branch, merge, and reproduce releases in your source control system?
There's "using source control" and then there's "using source control effectively". Plenty of teams use source control as a way to backup their source code. The thought is "if it's in source control, it's safe". That's all fine and good, but it's really only the tip of the iceberg. The real advantages of source control are parallel development and release sets.
Parallel development is the ability for each developer to work on any part of the system without preventing other developers from working on the same part. If you're using branching in your source control system effectively then all of the developers on your team should be able to work full speed all of the time. As they develop features or fix bugs they should be able to build and test based on their version of the code base. Once they're happy with their changes, these changes should be safely merged back in to the public code base. If you're a Big Swinging Developer, you should be able to go to the whiteboard and draw a branching strategy that supports parallel development. You should also be able to teach those with limited source control knowledge how (and why) to branch and merge. Given a source control system that you've never seen before, it should be less than a day's work to learn how to perform these functions since the theory is the same regardless of the technology used.
Release sets are the ability to reproduce the code base at any important point in time. An important point may be a release to the testing team, a beta release, a version that shipped, or any other milestone. Release sets are usually handled by labeling or tagging within a source control system. Once again, regardless of how the technology handles the function, you should know how to reproduce the code base for a given release. For bonus points, you'll champion ways in which to interrogate a system in order to determine its version. Things like assembly versioning, file versioning, versioning in config files, or a database table that knows the version of its schema are critical when someone reports a problem and you need to determine what version of the code to recreate. Of course knowing the version of the system that's having the problem isn't particularly valuable if you don't know what code went into that build which is why having your release sets in place first is so important.
Knowledge of version control theory and branching strategies is important, yet often overlooked. I worked at a place that wrote .NET code and the developers used Windows, Visual Studio, and their version control system all day every day. Everyone knew Windows pretty well. Everyone knew Visual Studio very well. Almost no one knew how to use the version control system well and their development speed suffered from it. If you learn the theory, you can learn the tools and you'll be one step closer to being a Big Swinging Developer.
Comments