The previous questions in The Big Swinging Developer Test referred to specific experience or skills. Part 1 is about branching and merging in version control. Part 2 is about creating a one step build. Part 3 is about build automation and recommends getting some experience with at least 2 different commercial or open source systems. Part 4 also recommends getting experience with a couple of different systems, but this time for bug tracking. Part 5 is about refactoring, which also involves having unit testing skills.
Before getting into part 6, I wanted to point out another difference between this test and the one it’s modeled after: The Joel Test: 12 Steps to Better Code. The main difference is that The Joel Test is used to judge organizations and The Big Swinging Developer Test is used to judge developers. The difference I wanted to point out, however, is that The Joel Test is used for negative gap analysis where missing something means that you’re in trouble. The Big Swinging Developer test, however, can be used for positive gap analysis where missing something indicates an area where improvement can make you more valuable. Looking over the past 5 parts it struck me that you can be a fine programmer and good developer without having any of the experience or skills listed. Add those skills in, however, and you can be an incredibly valuable developer who improves any team or company where you work. Now, a little about schedules.
The Joel Test: 6. Do you have an up-to-date schedule?
The Big Swinging Developer Test: 6. Do you raise risks that could affect the schedule before they become issues?
This seemingly simple question is actually asking 3 questions at once. The first is: "Do you know the difference between a risk and an issue?" A risk is something that may go wrong. Risks can be mitigated, accepted, or (in some cases) transferred. An issue is something that has gone wrong, or is going wrong at the moment. Risks are harder to identify than issues because they involve thinking about what may happen rather than pointing out what’s going on and why it’s bad.
That brings us to the next question: "Can you identify risks in a project?" A lot of developers can be given a task list or work breakdown structure and come up with workable estimates. It takes a special developer, however, to look at the plan and identify that the integration point that they’re dependent on may not be ready in time, or that their team may spend more time than planned supporting the previous release, or that it’s going to be monsoon season in India, where some of their critical resources live.
The meat of the question, though, is: "Do you have the confidence to raise risks?" I’ve worked with plenty of developers who report that everything is going swimmingly up until the day that things go supernova. This is usually preceded by weeks or months of sitting in meetings where another developer is reporting a less rosy, but more realistic, outlook that causes extra risk mitigation work on the part of the project managers or development managers. Believe me, the weeks or months of being known as "the easy team" are instantly forgotten and replaced by feelings of "why didn’t you say something sooner?" once the jig is up and their risks have turned into issues that have far fewer (and typically less pleasant) options.
Bad developers keep risks to themselves and try, in solitude, to keep them from becoming issues. Mediocre developers simply get blindsided by issues because they weren’t giving enough attention to the bigger picture. Big Swinging Developers know what can go wrong, are vocal about it, and give the rest of the project the chance to choose how to deal with risks.
The Joel Test: 5. Do you fix bugs before writing new code?
The Big Swinging Developer Test: 5. Given a piece of ugly code do you refactor it before adding new functionality?
This is the first time that the 2 tests seem to be talking about different things since refactoring is not the same as bug fixing. The key here is that it isn’t a question of technique, it’s one of discipline and motivation. A lot of organizations are feature oriented. They feel judged based on the quantity of functionality delivered and will try to maximize quantity at the expense of quality. I’m pretty sure that this question made the Joel Test because it tells you a lot about the medium-to-long term outlook for working in such an environment. Imagine being given no time for defect fixing post-release. Or worse, being told that you get no time because, "You should have done it right the first time." Oy!
The Big Swinging Developer question tells you a lot about the medium-to-long term state of your code. Let’s take the typical example: You’ve inherited a bunch of code that was written by several people. You can see places where something started to rot and then was made worse by each subsequent developer. Nested "if" statements get deeper. "Switch" statements get more and more cases. Methods grow to screen, after screen, after screen of spaghetti. You get the idea. After being given this mess and told to add functionality to it, do you create another layer of mess or do you take the opportunity to put a stake down as the the beginning of things getting better?
As you might imagine, the decision gets easier as your refactoring skills improve. If you’re already comfortable with unit testing, cyclomatic complexity, and have read Martin Fowler’s excellent book on the subject then you’re more likely to jump right in. If you’re a bit squeamish, however, then that’s a pretty good indication that this is an area to build up your skills. Fortunately, this is pretty easy and the practice work will be beneficial to you and your employer.
Refactoring starts with writing unit tests. Unit tests tell you that you are retaining the original functionality, which is a refactoring requirement. You can always add/subtract/edit functionality after refactoring, but you can either be refactoring or changing functionality – never both at the same time. Once you have a suite of effective unit tests (which is an immediate benefit to your employer) you can start cleaning and simplifying the code. The links above will lead you to some excellent sources for information and techniques on how to do this. Change the code, run the tests, repeat until satisfied. After only a little experience with refactoring you’ll be much more likely to leave any code you touch in better shape than when you inherited it and making things better is what being a Big Swinging Developer is all about.
The fun part of being a Big Swinging Developer is thinking about how things should be. You have a large collection of processes, techniques, and patterns in your head and you get to apply them to your organization carte blanche while thinking about what should be. Every book, article, and blog post that’s ever made you say, "Wow, I wish I could do that where I work!" migrates from the back of your mind to the very front and all of a sudden you know The Way It Should Be.
There are a few paths at this point. The more introverted developers will internalize The Way It Should Be and whenever they encounter something that Simply Isn’t Right, they’ll complain and tell others as much. Sometimes this falls on helpful ears and things get corrected. More often, the complainer develops a reputation of, well, A Complainer.
A more extroverted developer may take a different path. Instead of internalizing The Way It Should Be and remaining quiet until counter example appear they’ll start spreading the word. They’ll tell everyone who will listen and even those who won’t. The Spreading of The Word will take on many forms from simple water-cooler/coffee chit-chat to full-on email screeds that get sent to inappropriate levels of management. Once again, this sometimes works but more often results in the trumpeter developing a reputation for being impractical.
The Big Swinging Developer has a more complete approach. Instead of stopping at dreaming about The Way It Should Be, a BSD will take a very close look at The Way Things Are. With these end points in hand, the next step will be to develop a plan of action. This plan can be as simple as deciding the next thing that needs to change or as involved as mapping out steps and dependencies from beginning to end. The format and level of detail don’t really matter because no one will ever see this plan. Why will no one ever see the plan? The plan isn’t a deliverable, the plan only lists the deliverables which are the changes that get you from The Way It Is to The Way It Should Be. Then the work of getting these changes implemented begins. None of this is as much fun as the dreaming phase, but as you might imagine it’s A LOT more valuable to your employer.
Judging yourself by what gets done forces you to act pragmatically. If you give yourself credit for talking, then saying things like, "We should replace our version control system." results in huge points because it’s such a big change. If you only give yourself credit for what gets done then, "We should replace our version control system." will most likely result in zero (or fewer) points because it’s not something that’s going happen. Now, if you can make this happen you will get (and deserve) the huge points.
So keep dreaming, but talk about it less and act on it more. Your organization will be moving on the path to The Way It Should Be and you’ll be on your way to being a Big Swinging Developer.
The Big Swinging Developer Test: 4. Can you recommend at least 2 pieces of software for your team to create a bug database?
Defect tracking has come a long way since Joel posed his question more than 8 years ago. His company, Fog Creek Software, makes a great one called FogBugz. There are many others such as open source Bugzilla, HP’s Quality Center (formerly Mercury Quality Center), and one of my favorites: trac.
Just like recommending an automated build solution, recommending a bug database comes down 2 things: What have you used? Why do you like it? This is an area where open source and free trial periods really shine. If you’ve used bug databases before, but never set one up, I recommend that you give it a shot. In general the installation is a breeze, or in the case of hosted solutions it’s non-existent. Post-installation is where the real fun begins.
Configuring a bug database is really an exercise in designing a QA process. What severity levels will you use? What categories do you break things into? Do you segregate defects, enhancements, and feature requests? Other than Open and Closed, what states will you put a record in? I’ve said it many times, but I’ll keep repeating it throughout these posts: It’s not about the tools and technology, it’s about the process and behaviors. Sure, it’s helpful to know about the platforms and integration points of a handful of bug databases available so you’re ready when the time comes. The real value, however, is in having thought through the defect process and being able to recommend something that fits the need, not just the requirement.