Starters and Finishers

Mariano Rivera is arguably the best closer of all time, with credentials that include a 0.77 ERA across 76 post-season games. Yet with a 5.94 ERA as a starter during his ML rookie season, he was only allowed to open ten games. Mo can't start, but he can most definitely finish. Even this Braves fan must acknowledge that.

Starters and finishers also clearly exist in the world of software development. I was reminded of that this week when a developer proposed changing a few accelerator keys (shortcuts) on menu picks, and a detailed dialog and email chain followed. Since I originally designed and built this system, I often either specify or review proposed changes. But in this case, I honestly didn't care, and refrained from commenting. Yet, I'm eternally grateful for those who do care about such details.

I've had the pleasure of working with many developers who excel as finishers. They're not plagued by the "not invented here" attitude that often tugs at starters like me. Rather, they'll take something over, make it their own, and tirelessly extend and support it.

Understanding "starter" and "finisher" personalities can help when staffing a well-balanced team. Martin Fowler describes starters as having the enabling attitude, while finishers possess the directing attitude. Starters make good architects, business analysts, designers, and trailblazers. Finishers make good project managers, maintainers, and support engineers. Nearly all software organizations need a good mix of both.

But we should avoid caricatures. This certainly doesn't mean that starters never finish anything and finishers never start anything. These labels shouldn't excuse procrastination (by finishers) and incomplete work (by starters). Starters should be required to stay with a system until it reaches maturity, and finishers should brought on early enough to understand its design and rationale. I've started about a dozen new large systems (and a few dozen smaller systems and feature packages), and have enjoyed staying with the products through GA of versions 1.x, 2.x, and 3.x. But my fondest memories are usually of early milestones (internal and alpha versions like 0.1 through 0.8), although these required a lot of round-the-clock hard work.

These personalities should also not be confused with quality measures. It is simply wrong to excuse poor quality from a starter because, "a finisher will clean it up."  Saves are exciting in baseball, but are poor process in software. Yet many finishers do have extra perseverance to help close the final details. For example, I've known finishers who code more bugs than the starters. But even if it takes ten tries to get it right, they'll doggedly clean them up.

The symbiotic benefits between starters and finishers are a good thing in software development, and should be encouraged, along with a healthy respect for each other. Just ask Mo.