I honestly wish that Part 8 didn’t exist. Question 8 of The Joel Test: 12 Steps to Better Code sits there pretending to be on par with the other questions, but it turns out to be in a league all its own. Here’s a quick recap of the subjects of questions 1 through 7 in the Joel Test and their Big Swinging Developer counterparts:
So what makes question 8 so different from all of these? It’s the one thing in the test that you can’t change.
The Joel Test:
8. Do programmers have quiet working conditions?
The Big Swinging Developer Test:
8. Can you get things done regardless of the working conditions?
At Microsoft I had an office that I shared with a designer. It was great. We were quiet except for the times when we both didn’t want to be. At BindView and Symantec I had a private office. It was even better. When I wanted quiet, I just closed (and possibly locked) my office door. At DuClaw I could work in any of our 4 bars, the brewery, or be at home. The bars, while certainly not quiet, were fun places to work and I could always go home when I needed quiet. My current gig, in stark contrast, is the single worst physical environment for programmers that I’ve ever worked in. It’s an "open floor plan" which fosters a "collaborative environment" whether you want it or not. I know plenty of programmers who would simply never work in this kind of office because they know how ineffective everyone becomes with all of the noise and the lack of barriers to interruption.
Being a Big Swinging Developer, however, is all about doing what others won’t or can’t and part 8 is the essence of this spirit. Reread the question, though. It’s not about tolerance or biting your tongue or just getting through. The question is "can you get things done regardless?", which is about adaptability and discipline. I’ve found that the open floor plan affects me less at 6am and on weekends, so when I need to crank things out, that’s when I work. I’ve also found that headphones, while not as effective as a door, are a key piece of survival gear when things get busy around me.
As I said in the beginning, I wish part 8 didn’t exist because programmers really are more effective when quiet is a choice. It’s also a shame that this is something that you just have to accept, like Houston weather or colonoscopies. Just remember: businesses choose open floor plans because they are much, much less expensive — and taxed differently — than real offices. Make sure that you can be effective regardless (and that they pass some of those savings on to you) and you’ll be a Big Swinging Developer that can work anywhere.
There’s a difference between "having a lot to do" and "being busy".
I almost always have a lot to do. I have a long list of tasks and projects that I’m interested in doing and I can productively work on that list at the drop of a hat. By the same token, I can usually stop what I’m doing and do something else if the need arises. There are certainly some tasks that require uninterrupted time, but those are easily accomplished in the "off-hours" of early or late. Most of the people that I enjoy working with structure their work similarly: they’re never "busy", but they are constantly making progress.
The people I least enjoy working with are the "busy" ones. These are the folks who feel buried by their tasks and often when asked to do something (and almost always when asked why something didn’t get done), their response is "I’m very busy". The worst part is that everyone seems to take being busy as a universal and unquestionable excuse instead of immediately responding, "Well how did you let yourself get into this predicament?". My friend, and never-busy-colleague, Jimmy C once pointed out that being busy is a choice just like being drunk is a choice. He likes to say, "Replace the word ‘busy’ with ‘drunk’ and see how much weight it carries".
"Sorry, I can’t help you out, I’m too drunk" or "He’s a very drunk person" or "I didn’t get to it yet, I’m too drunk".
Really takes the teeth out of the statement doesn’t it?
I’ve spent too much time over too many pints* trying to figure out why the busy people are the way they are. Poor time management? Unrealistic estimates? A need to feel more important than they are? Guilt over their bill rate? I finally realized that answering the question wasn’t productive, so I stopped thinking about it since I have a lot to do.
So stay productive and don’t get too busy too often.
Question 7 in The Joel Test: 12 Steps to Better Code is about knowing what you’re building. For an organization this often means a spec. It almost always meant having a spec when the Joel wrote the test in 2000. These days writing a technical specification is out of fashion in a lot of startups and small teams. While the method of documenting it may become unfashionable, knowing what you’re building never goes out of fashion.
The Joel Test: 7. Do you have a spec?
The Big Swinging Developer Test: 7. Can you gather requirements?
The term "requirements" is one of those words in development that everyone knows, but doesn’t always agree on the defintion. Some folks think of hundreds of pages of text that comes from a wicked-expensive consulting firm and always starts with "The system shall". Others may think of User Stories or some other agile term because the most agile aspect of agile development is, in fact, the terminology. My personal definition is "knowing what the system needs to do in order to be considered a success." I split this incredibly broad statement into three buckets, based on who is affected by the decisions made. These folks, incidentally, are the same ones who should be consulted throughout any requirements gathering phase.
Group 1: The Users This one may seem like a no-brainer, but if that were the case then fewer companies would get it wrong. Gathering requirements from users is all about finding out how they approach the problem that you’re trying to solve. Getting this information can be as easy as asking the following questions:
What are you currently doing that works well?
What are you currently doing that’s difficult?
What is it that you wish you could do, but currently can’t?
What is it that you currently do, but wish that you didn’t have to?
Note that "gathering requirements" is different than "writing requirements". Being a Big Swinging Developer means adapting to your environment, so if you’re in a consulting role in a large org, that may mean firing up Rational’s RequisitePro and cranking out your findings in "The system shall" format. If you’re in a smaller and (dare I say it) more agile environment, it may mean that all documentation must be submitted on cocktail napkins.
Group 2: Other Developers The single most ignored source of requirements is hiding in plain sight: other developers. The chance of you being the only developer to work with your app is indistinguishable from zero. Whether it’s integration, enhancement, maintenance, or whatever else, other developers will need to use your stuff. This is where things like plug-in architectures, configuration flexibility, and APIs come in. Or ask how your code will be tested for both functional completeness and performance. Look down the road and picture what future developers on the app will need, much like you look down the road to picture what users will need. If you’ve never thought about it before you’ll be amazed at how all those little decisions can affect the success of the app in the future. One of the reasons that developers get ignored as a requirements source is that most developers consider these types of decisions to be design decisions. But how can they be design decisions if the requirements are unknown? If you think that you know everything there is to know about what an app will ever need then you’re probably impossible to work with. Learn how to ask and it’ll pay off big time.
Group 3: Operations One of the things I learned from the really good developers at BindView was that software needs to participate well in a network ecosystem. This means that everyone runs their network a little differently and you need to meet the network’s needs rather than requiring the network to meet yours. This is especially true in enterprise software, but it still holds true for web apps since you have folks running the hosting setup. Operations requirements is everything from installation, to provisioning (i.e. adding new users and reference data), to security (I pity the fool who releases a Windows app that doesn’t support AD groups), to logging (for monitoring health and errors), to backup (including archival/retrieval of old data). If you’re doing in-house development then this can be as easy as talking to your operations folks and you can even use the list of 4 questions above. If you’re selling commercial software, make sure you talk to your customer’s network admins about their needs. Nothing will kill you in a purchasing bake off like the inability to play well with Operations.
In the list above, you’re only responsible for being a representative of the second group. You don’t have to be an end user of the system and you don’t have to have extensive operations experience. What you need is the ability to talk to these folks about their need, but above all else you need a genuine respect for the impact that your software will have on them.
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.