Big Swinging Developer

The Big Swinging Developer Test - Part 5

In part 5 of The Big Swinging Developer Test (a parallel to The Joel Test: 12 Steps to Better Code) we get into refactoring.

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.

You Only Get Credit For What Gets Done

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 - Part 4

This is the 4th part of the series that presents a test similar to The Joel Test: 12 Steps to Better Code, but for developers rather than companies.  Previous entries: part 1, part 2, and part 3.

The Joel Test:
4. Do you have a bug database?

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.

The Big Swinging Developer Test - Part 3

See Part 1 and Part 2 to catch up, but the short version is that this test is similar to The Joel Test: 12 Steps to Better Code except for developers rather than companies.

The Joel Test:
3. Do you make daily builds?

The Big Swinging Developer Test:
3. Can you recommend at least 2 pieces of software for your team to create an automated daily build?

As mentioned in the previous post, the less code you write for your infrastructure, the more valuable you are.  Any time you can use off the shelf or open source software, it means that you have more time to focus on your specialty.  Automated build software is a great example of this because it's one of those problems where the first 80% or so is really easy: It's a scheduler, some configuration, and a way to notify you about how things went.  The last 20% - things like variables, macros, conditionals, monitoring, and the million other things that we've come to expect - can eat up an incredible amount of time an effort.

The good news is that there are a lot of great build systems out there.  The challenge is in knowing which to choose and then implementing it quickly and correctly.  This is where experience really starts to pay off.  If you've had to implement one of these systems in the past, you're ahead of the game.  Even if you've used one that you really like, you're in pretty good shape.

The better news is that getting experience with a build system is really easy: automate your current project.  Try a couple of different systems for bonus points.  Not only will this put you in the valuable position of being able to improve everyone's productivity, it'll also teach you a lot about your project's structure (or lack thereof).  The types of problems that you encounter when automating a build will cause you to think differently about all of your future projects.  As you've probably figured out by now, thinking differently is one of the cornerstone's of being a Big Swinging Developer.

The Big Swinging Developer Test - Part 2

In the previous post I started talking about The Joel Test: 12 Steps to Better Code, which gives you a quick measure of software development organizations.  The Big Swinging Developer Test is similar, but instead of sizing up organizations, it's used to get a quick read on a developer.  Now, on to step 2.

The Joel Test:
2. Can you make a build in one step?

The Big Swinging Developer Test:
2. Can you create a one step build from scratch?

At first glance, this seems to be one of the easiest development tasks ever.  Build in one step?  Sure, just click the green triangle in Visual Studio (or the equivalent step in Eclipse, Sun Studio, etc.)  That's not one step since you'd have to open the project in one of those tools to begin with.  In addition, what about getting the latest code from version control?  Not to mention the likelihood that the program you're working on will be spread across multiple projects.

Like all things Big Swinging Developer, creating a one step build is less about technology and more about process.  This one in particular requires a large dose of empathy because "it builds on my box" just doesn't cut it when you're working in a team, especially if you're getting a monster bill rate to do so.  There are three audiences for a one step build and if you can meet the needs of all three then your life will be easier on just about any project you join.

Audience 1: The New Guy
Have you ever joined a project and spent the first couple of days just trying to get your development system set up?  One of the most frustrating parts of the on-boarding process for any developer is getting to the point where you can start debugging, writing, and testing code.  A successful one step build for The New Guy is a single command from a logical place (like the root folder of version control) that requires either zero parameters, or gives him the list of parameters when none are passed in.  There should be no need to train him to build other than, "Run this command from this directory.  Catch you later."

Audience 2: The Team
The second audience is the rest of your team, or the teams that you work with in the case of a large project.  Since team members have different needs, this is where options, parameters, and structure come into play.  Maybe team members don't want to build the whole system, so you break the build into sub-builds that can be run independently which are then all aggregated into the top-level master build.  Maybe the team wants to run some tests, but not others.  I was on a project once where there were more than 250 .NET assemblies built as part of the system.  Compile time was about 7 minutes.  Test time was nearly 3 hours.  Even though I was paid hourly, I didn't need to run all the tests all the time.

Audience 3: The Build/Release Team
The final audience may or may not exist on your project.  Sometimes you have dedicated release managers and sometimes you just have someone appointed to produce release builds.  Either way, this audience has their own special needs.  In particular, the ability to do things like build in Release/Optimized mode, the ability to synchronize version numbers across files, the ability to deploy to new directories, and more.  A one step build that compiles, tests, packages, deploys to a timestamped directory, and emails everyone who cares is a thing of beauty.

NOTE: The less code you write, the more valuable it is.
You may be thinking, "No, problem.  Some Perl here, some DOS batch files there, throw in that hand rolled FTP client I wrote awhile back and I can build everything listed."  Not so fast.  A good build system is built on technologies that folks can understand, use quickly, and Google for help.  Think Ant, NAnt, MSBuild, CruiseControl, WiX, even Make.  Remember: Build something that people can use and improve even when you're not around and you're on your way to becoming a Big Swinging Developer.

The Big Swinging Developer Test - Part 1

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.

Version Control Skills are the Knife Work of Development

Being a Big Swinging Developer is kind of like being a chef in a professional kitchen.  There's a lot of pressure, a lot of money on the line, and a lot of cursing.  One of my favorite analogies from the cooking world is knife work and the difference between professionals and home cooks. 

The key to not cutting yourself in the kitchen is to keep the knife from making unwanted contact with your body. 

The home cook approaches this problem by eliminating the "contact" portion of the equation.  They'll cut slowly and deliberately in order to keep the knife away from their fingers.  If you've ever watched a professional, however, you'll notice that they put the blade against their knuckles and can cut very, very quickly while keeping all of their digits.  Professionals remove the "unwanted" portion of the equation.  Why does this matter?  Because professionals cut all day long and the better their knife work is, the more they can accomplish.

A defect is incorrect code that gets released into the wild. 

There are two parts to this equation as well: Don't write incorrect code, or don't release it into the wild.  The beginning developer will take the first approach with the thought that writing great code is what it's all about.  The seasoned developer knows that releasing great code is what it's all about and that mistakes happen.  This is why unit tests, continuous integration, one step builds, etc. are so important: the more test shots you get, the more defects you'll catch, and the better your released code will be.  These tests and builds need to happen in isolation --on private branches, for example-- rather than occurring in the wild.  The ability to use your version control system well is like being a chef with strong knife skills: you'll be able to experiment more, build more, test more, and simply do more than the developers who are too afraid of cutting themselves.

So learn your tools and use them with confidence.  Move faster (and more safely) than everyone else and you'll be a Big Swinging Developer in no time.