The Starter, the Architect, the Debugger and the Finisher

http://jacquesmattheij.com/The+Starter+the+Architect+the+Debugger+and+the+Finisher

by prez • 14 years ago

328 66 14 years ago

euroclydon• 14 years ago

I've found the reasons why I sometimes don't want to wear all four of these hats are mainly personality defects. It is possible to work for another year on the non-creative parts of a project, it just takes discipline.

PaulHoule• 14 years ago

"The debugger couldn't be paid enough money to start from a blank page in order to get something new started."

Perhaps it's different in S.V. but in the workaday world of the code mines I've found that the Debugger doesn't get all that appreciated. Rather, management likes the starter since he seems so productive... after all, he just did the 20% of the work that got us 80% of the way there. They just wish he could somehow do 25% and get 100% of the way there.

dalore• 14 years ago

Yes but isn't the rule that last 10% of a project takes 90% of the time?

Periodic3• 14 years ago

From my experience as an enterprise coder I saw a management that didn't understand that there were bugs. Everything was supposedly done with Scrum, so at the end of each two-week sprint there were supposed to be no more bugs left on that feature. As far as the schedule was concerned (and we were scheduled over a year in advance) bugs didn't exist.

When bugs were found that the engineering team had to fix, we were either supposed to do it in addition to our other tasks. And any major bug required a huge rescheduling meeting to figure out how we can still make our schedule now that we had lost 20 engineer-hours.

Also, with their focus on "individual ownership" they expected everyone to take a feature, implement it, and fix all the bugs without involving the other engineers.

What this lead to was a lot of buggy code, a lot of obvious bugs that didn't get fixed and we just crossed our fingers over, and a lot of people acting as starters even though we had and needed more finishers, debuggers, and architects.

c1sc0• 14 years ago

When you put it in sequence like that it seems like the Starter & Finisher are far removed from each other, but I find the opposite to be true. What these personality types has in common is an appreciation for beauty. The Starter just loves beautiful ideas while the Finisher loves beautiful user-faceing implementations.

skrebbel• 14 years ago

Nice article, but IMO it's essentially a software-specific version of the Belbin Roles[1].

[1] http://en.wikipedia.org/wiki/Team_Role_Inventories

    Starter -> Resource Investigator
    Architect -> Shaper
    Debugger -> Teamworker
    Finisher -> Completer Finisher

Roughly.

What I miss most in Jacques' article is the Plant, the person who thinks things over and then comes forward with problems, issues and risks in the chosen approach. It's, fortunately, a very common trait among SW engineers though, so I guess every team has at least a bunch.

drsim• 14 years ago

Nice

aercolino• 14 years ago

Maybe this is better:

  Architect -> Plant + Specialist
  Starter   -> Resource Investigator + Shaper
  Debugger  -> Completer Finisher
  Finisher  -> Teamworker + Implementer

zipdog• 14 years ago

A similar system is discussed for CEOs as well. The entrepreneur who starts a company is not always a great consolidator who gets everything settled and organised into a functioning whole once the money starts coming in. The next two I think are substantial growth (being able to take an established business and grow it into a dominant player in its industry) and the last I think is something like holding, being able to take a large (and usually somewhat unwieldy) business and keep it from losing ground.

There's probably a few variations on these as well (and I might be misremembering them slightly).

ZeWaren• 14 years ago

This reminds me of role variants in the Keirsey Temperament Sorter.

http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter

Swizec• 14 years ago

Personally I'm a starter. Great at implementing prototypes, getting things working fast, but absolutely terrible with polishing things and taking care of edge cases.

And I hate it. I consider it a personality flaw, a flaw in my work ethics, and so on. Whatever it is, I don't want to have it.

What I've found has helped me get beyond this problem is taking on freelancing gigs where I'm mostly the guy who gets a rough prototype and has to make it work. The beauty of this is that I know how to think like a prototyper, so I can become productive on a foreign codebase quickly.

And because I started at a different goalpost, I can still work as a "starter" even though I'm doing the job of a "debugger/finisher".

follower• 14 years ago

> I consider it a personality flaw, a flaw in my work ethics, and so on.

I'm curious what percentage of software developers self-identify as finishers and what percentage as starters.

My assumption is that starters are much more common--but maybe that's because I assume everyone is just like me.

Are there really software developers who fit the "finisher" description? And prefer it? :)

If it turns out that software developers really do have a range of roles available to them and each individual suits some more than others then maybe it's best to work to accept it rather than feel guilty about it?

vladd• 14 years ago

I've seen successful finishers. You can see them hang out around sites like www.flippa.com , looking for that special project that they could buy and operate as owners for a quiet life and sustainable revenues.

benjaminwootton• 14 years ago

I'm a good starter and a good finisher. It's the middle of the project where my motivation can dip, particularly on side projects.

I love taking a seed of an idea and running with it into prototypes etc.

And I also love doing that final layer of polish, trying to break my code and handle edge cases and tweaking user experience.

I think it's because I approach the start and the end from the users perspective, but then the middle of the project can sometimes feel a bit disconnected from the user.

Something like writing your persistence layer doesn't really feel as though it's contributing to the vision of what you want to build.

aurelianito• 14 years ago

> My assumption is that starters are much more common--but maybe that's because I assume everyone is just like me.

If finishers are less common than starters, shouldn't they be payed more? Are they being payed more? Is it a flaw in the market?

adestefan• 14 years ago

I'm a a debugger. I can't stand to look at a blank screen since I never know where to start. However, I love it when someone toss a difficult bug at me. I can spend days pouring over code in nothing but a debugger and live for the rush when a simple change fixes everything.

We have a running joke on my team that I come out of the bullpen as the setup man and hand it off to our closer. We'll have meetings where it comes and my colleagues will say, "Put him in coach." It works for us since most people are starters and one guy is a great finisher.

jordhy• 14 years ago

The article it's ok, but this is just a permutation of the roles first outlined in the Mythical Man Month (lawyer, surgeon, organizer, etc).

TamDenholm• 14 years ago

I consider myself a good starter and debugger, I really suck at finishing, i hate all the little polish bits that are left over to do.

I find it easier to be the finisher if i didnt start the project, perhaps i should partner with someone with the same problem and just swap our projects once we get to the finisher stage.

Aqua_Geek• 14 years ago

I also consider myself to be a starter and debugger. I have dozens of half-baked projects in the project graveyard on my hard drive.

I think part of my problem is what's described in the article - I start the project, solve the hard problem, and then move on to learn something else.

Any finishers out there have any tips? What drives you through the slog of the last 10%?

edw5192• 14 years ago

I believe that in order to get really good at any of these roles, you must do the other roles, deeply and often. For example:

The more time you spend Debugging shit, the less likely to you are to Architect something that produces shit.

The more time you spend fixing a million little things caused by poor early decisions, the better Starter you'll become.

The more fun you have conceiving and Starting projects, the more you'll realize how important Finishing is, so that you can get to new stuff.

And the more time you spend doing each of these roles, the better you'll get at doing all of them at the same time, and understanding what conditions are needed to do that. (Hint: Lots of quicker smaller complementary projects that you can wrap your whole head around.)

[This whole discussion reminds me of the time I was a restaurant manager and got tired of the servers and cooks bitching at each other. I had them switch roles for one shift. Once they understood how what they did affected the other, everyone got a little better and the bitching stopped.]

revorad• 14 years ago

Did you try switching roles with a cook or server? That would have been fun :-)

edw5192• 14 years ago

No need for that. I had already done every job and knew exactly what would happen.

But your question reminds me of another time when I did do that. I was the IT Director and got tired of the lead programmer bitching about my decisions. So we traded jobs for one day. I had a great day just coding. He made 5 decisions. On each one, I pointed out about 5 things he didn't take into consideration, making his decision less than optimal. He was glad when that day ended. (And I was glad when that job ended; I've been coding ever since.)

kiiski• 14 years ago

How did your customers like the food made by servers, and the serving done by cooks?

geebee• 14 years ago

I would agree that people learn from being involved in all phases of a software project at least once. Especially starters.

Starting a project is an exciting, heady, creative time. If the last 10% takes 50% of the effort, the first 90% is where you create and build at a fast pace, enjoy the adulation of your clients who are amazed with how quickly things are going, investigate and implement interesting new technologies and approaches, and revel in the fun of creating something new.

The question is, did you leave the code base in good shape, or did you go on a bender, drinking the champagne but leaving your successors to experience the hangover? My guess is that most people on this board have had to deal with a truly bad code base, in production, inherited from a programmer who flitted off to the next project cause he "enjoys the challenges of creating new things".

Until you've been the debugger who fixes the million little problems, the "architect" (wish we had a different word, cause you will be coding a lot) who refactors the code into something that can actually be maintained, and the finisher who experiences the irritated grousing of clients (who notice that things have slowed down so much since the "starter" left the project... we just asked for it and he did it), you don't know the kind of damage a rogue "starter" can do.

scotty79• 14 years ago

The more time I spend Debugging shit the less likely I am to Architect or even Start anything because I am painfully aware that everything produces shit.

EDIT: Wow. A downvote. That what I get for showing the pain I experience to the world. :-)

wisty2• 14 years ago

So what you are saying is - you write better code, reduce lines of code, don't be too clever, reduce complexity, and use well-proven libraries.

jerf• 14 years ago

The way over that hump is essentially to realize your implicit baseline of "not shit" is unrealistically high. An architect should strive to not produce shit, but also has to be able to emotionally deal with the unattainability of that goal. No sarcasm, I've seen people who can't deal with that. An architect must also have just enough ego to believe they stand a chance of being able to produce something less shitty than would otherwise be produced without them, while at the same time not being so egotistical that they lose touch with the users of their architecture, which is a fatal error, or even worse, become actively arrogant. (You are still producing shit, after all, and don't you ever forget it.) It's a delicate balance.

An essay that had a significant impact on me and the development of this attitude, the first few paragraphs of: http://scripting.com/davenet/1995/09/03/wemakeshittysoftware...

taeric• 14 years ago

The danger I had when I got good at debugging, is I came away with the belief that I needed to make mistakes impossible to make. In that regard, I did exactly as you say is unlikely. I left a world of debugging and wrote some highly over engineered crap. Pulling things back to make the mistakes obvious, not impossible, I've had much much more enjoyment.

I can also say that the thing you really need to do is use what you are programming. Or at least something like it. I don't know as that this is cross cutting, in that someone that uses a product may not be good at building it, but they are probably good at selling/describing it.

stusmith1977• 14 years ago

Completely agree. I once worked at a bespoke software shop where they had 'proper' developers upstairs, and support developers downstairs. (Quotes used to indicate how that made the support staff downstairs feel).

Most projects taken on by the company followed the same path: upstairs developers would code up the application as per functional spec, client would do a bit of UAT, accept it, publish it live, at which point the project was assigned to the support staff.

What generally happened next was the application would begin to fail on non-functional fronts, generally appalling performance and scalability problems.

Since there was minimal communication between floors (afterall, what could a 'proper' developer learn from a lowly support developer?), the pattern repeated again and again.

I'm sure that either rotating the positions, or having individuals responsible for staying with each application throughout its life, or some other form of mixing, would have drastically improved both morale and quality of apps produced.

amirmc• 14 years ago

What you've described is fundamentally a problem of communication.

You don't need to do multiple roles in order to understand them. You do need to listen to the feedback from each different area and then act on it so that your decisions don't create unnecessary work for others.

The restaurant scenario is one I've heard before and it's the literal version of putting yourself in the other person's shoes. Not workable in every situation (but kudos for having the balls to do it.)

tseabrooks• 14 years ago

My first job in embedded systems required everyone to do pretty much all of these things. Each developer handled their own modules from user facing UI through to the HW (more or less). We had to architect and design things before implementing them (No one checked.. and it wasn't enforced... it's just the way the culture works) we then became individually responsible for implementation and bug fixing until the QA dept said it was A+.

After that there was a module review by 5 randomly selected engineers that would tell you what parts of the module was a messy hack and make you go fix it. I miss this culture.

ludflu• 14 years ago

good article. I've found myself in various of these roles in different jobs. But it really is hard to do them all in the same project.

darylteo• 14 years ago

I associate myself mostly as an Architect first, Starter second.

There is nothing more than I'd like for someone to just take some designs I've drawn up, critique if necessary, and then get it done. Generally, I get so stuck in the big picture that I have great difficulty getting anything done :(

I CAN debug... often I can identify a problem just from a general description of the problem (when you see me sit down in front of a computer and take over, it's when the problem has dug in deep). Sadly, with all the maintenance work I have to do with some legacy systems, debugging them is not a task I take to fondly.

Definitely not a finisher... I'm a sprinter, not a marathon runner.

jpdoctor• 14 years ago

It would be interesting to run an HN poll: Which of these rolls are you mostly associated with?

My guess is the population here is dominated by Starters and Architects.

ClintonWu• 14 years ago

This post also helps us non-technical types when interacting with technical co-founders and the engineering team. I realize my partner is definitely a starter and not a finisher!

CPlatypus• 14 years ago

Another metaphor I've seen is to the military (specifically the army), and consists of three roles. Don't beat me up about military minutiae, please; I don't claim to be an expert in that area and it's not even my metaphor.

(1) Paratroopers, who jump into unfamiliar territory. In software, researchers and architects.

(2) Infantry, by far the largest component, responsible for the core task of taking and holding territory. In software, most programmers.

(3) MPs (also quartermaster, community liason, etc.) who maintain order in the held territory. In software, debugging specialists and release engineers.

The problem I have with the OP's metaphor is that the "starter" and "architect" roles are both part of (1) and many people actually can do both pretty well. Similarly, the "debugger" and "finisher" roles are both (3) and also combine well. What's really unfortunate is that (2) seems entirely absent even though in real life it consumes most of the time and resources on a project. These are the folks who take mostly-complete designs from a starter/architect, and get most of the code mostly working before the serious integration/stress testing occur and the debugger/finisher come to the fore. In other words, most of your colleagues most of the time. If you hired four people according to these four roles, you'd have nobody to write most of the code and you'd be abusing your four specialists to do it.

Jd• 14 years ago

One important thing to note is that you can be good in all of the roles but not be able to do all of them on the same project. For example, I find personally that I have a very difficult time being a finisher and starter on the same project -- after a certain point exhaustion takes over. Also, I love to debug things, but, again, after you've spent countless hours debugging you might run into the problem of exhaustion.

This is, among other reasons, why I like the YCombinator emphasis on co-founders and teams. Even if you are a superstar you need people around you to work at maximum efficiency (speaking for myself at least).

Also, I'd like to applaud the backstage people (accounts, etc.) that make other things possible. Even when I do reasonably well in all of the roles mentioned in this article, I absolutely fail in the paperwork department.

nadam3• 14 years ago

I find it very hard to characterize myself, I constantly struggle with it. I enjoy starting things and don't like finishing/maintainging other peoples code especially if I cannot see their philosophy.

When trying to figure out where my limits are I found out another characterization:

- fastness

- deepness

- input bandwith

- memory (forgetfulness)

Compared to an average person I am good enough in all of these, but compared to A players I am bad in all of them except deepness. Compared to the very best I am slow to learn a new technology, slow to solve problems on the whiteboard in real-time, I have to re-learn things because I have partly forgotten them, and I am not especially fast in learning other people's theorems, proofs, and algorithms. I ocnstatnly find lots of stuff bullsiht and I constantly question basic beliefs, so I am slow at processing outer information. What I am quite good at is getting a challenging task and thinking about it for a lot of time refactoring my thoughts hundreds of times until I come to interesting insigths. Not that I am that good at it, but I have huge patience for this, because this is what I enjoy. It is more than enjoying this: my brain needs this as a drog. My brain pretty much likes to be detached from the outer world for long-long sessions.:)

When solving easy tasks this does not come out. But when pushing my limits I experience these weaknesses / strongness.

Periodic3• 14 years ago

Would you please expand on your four characterizations, explaining what this quality is, what it makes someone good at, and maybe an example persona that exemplifies it?

The four adjectives don't immediately create images in my mind of what qualities they represent.

nadam3• 14 years ago

I try to expand on the 4 metrics I came up with:

fastness:

This can be measured by giving the person a not too hard (but not completely trivial) algorithmization problem, and see whether he/she can solve it in 15 minutes. Someone 'fast' is usually very good at competitions or at interviews excercised by companies where interviews are quite intense like Google.

deepness:

This basically means that given a much harder problem than the previous one, how the person solves it given lots of time. This is different than the previous one. Can he come up with a quite original "theory"/(thought system)? How fast a ray tracer he can write in 3 months? How good domain specific language he can come up with for a tricky domain in 2 weeks? (vs. writing the implementation for the Dijstra algorithm in 30 minutes without mistakes, which is 'fastness')

- input bandwith

How fast you can read a reasonably dense technical/algorithms/math book. How fast you understand other people's nontrivial ideas? This is not totally the same thing as how fast you come up with an idea, or how good an idea you come up with yourself.

- memory (forgetfulness)

How big a system / requirements spec. document can you hold in your head? If you used C++ 3 years ago, do you need to re-read the book 'The C++ Programming language' or you remember more or less everything? If you look at your previous comments on Hacker's News, are you suprised by some information in your own comments or you remember more or less everything?

pkandathil• 14 years ago

I am opposed to the concept of having a architect that does not code. Too often have I seen the situation where they recommend a solution without understanding the complexity of the implementation.

fabricode2• 14 years ago

> The Starter, the Architect, the Debugger, the Finisher

and the Stereotype.

These articles aren't very informative if they don't have some new insight into how to maximize the output of the team by exploiting the traits of the stereotype. The roles outlined in this entry really only fall into two categories: get things going (starter & architect) and get things working (debugger & finisher).

If I had to take a wild guess, I'd say that what the article is really trying to say is that it's easy for people to start projects (I've yet to meet a "debugger" that can't start their own), but it's hard to complete them. It's often even harder to keep something working than when it was put together given the nature of changing requirements.

So my take on the article would be to add the advice: if you consider yourself a "starter" or an "architect", go live in the world of maintenance for a while. Learn to complete your projects. And if people tend to curse a project when your name was on the design doc, perhaps you should spend a bit more time learning about practical programming, design, and algorithms... or mentor with someone who is well regarded.

Next week's article: What happens when the boss is a Sagittarius and the team lead is a Gemini?

jacquesm3• 14 years ago

> What happens when the boss is a Sagittarius and the team lead is a Gemini?

I don't know, will you write it?

If you missed the message on what you could do to 'meximize the output of the team', without taking a wild guess, it is there in the next-to-last paragraph.

Whether that's a novel insight or not is up to you, it is novel enough to me that I chose to write about it. I'm still trying to work around my tendency to start stuff and not finish stuff and having been tossed into the role of debugger/finisher lately has helped me to be both better at starting stuff and to get more appreciation for the people that work on later stage code.

fabricode2• 14 years ago

I did catch your conclusions in the penultimate paragraph. However, I don't believe that "assigning [a] quality control role to the next person downstream" is a workable solution. This is a form of passing the buck, saddling someone else with your problems, etc.

In your reply here, you say that you've learned that by working as a debugger/finisher you've learned how to start stuff better. That is worthy of further exposition as so many people suffer from the exact same problem.

And as much as false categorization & naming hurts your best point, it sure seems to have caught HN's attention, so marketing may be where your true genius lies. That's cool -- there's lots of money in marketing :)

larsberg• 14 years ago

When I worked at MSFT, we used to break up (senior) people according to which stage of the project they were better at leading, either as technical ICs or managers. If you chunk projects into four parts: early, build-up, build-out, and release (not the words we used --- we just used numbers 1-4), almost all senior people tend to do best at some close span of two of them. I was personally frequently slotted into 1/2 roles, but I knew lots of others who fit more into 3/4 roles. It's a mixture of personality type and skillset.

Few things can doom a project more quickly than putting a "shipper" in charge of an early-stage project or vice-versa. You end up with management that sends all the wrong signals to the team and everybody can tell is looking forward to some later stage.

Of course, for junior people, it's important to just make sure they get through all of them. Not just to pick up the skills mentioned by other commenters here, but also to see which they're good at for when you want to stretch them with a leadership role, without setting them up for an avoidable failure.

debacle• 14 years ago

Often times, The Starter and The Debugger are the same person - the person who approaches programming challenges like affronts to their ability. Once the hard problems are solved, it's just a bit of tidying up and you're set.

I find it very difficult to be a Finisher, and I think many programmers do. Finishing isn't fun, it's not glamorous, and it's not why we do the work, but it's a skill that we need to develop.

I've noticed a trend in my own development. When I first start a project or I'm working on a hard problem, I'm working 10-12 hour days figuring out the interfaces, making the object model pristine (or as pristine as it can be in the language I'm using), making the error messages helpful and the exception handling consistent.

And then, as I'm closing out the project, I start to lose focus. I start watching the clock. I'm out of work as fast as I can. I'm doing, for lack of a better word, the bitch work, but the bitch work is what makes the system.

I've tried to get better at it, but I think there is a fundamental issue with the project lifecycle that makes human beings phone it in in the last bits of a project. Whether it's building a house or writing an application, those last bits of the project seem the most arduous.

Bjartr• 14 years ago

Does anyone have advice on how to become a better finisher?

jacquesm3• 14 years ago

Take any project (open source is easiest) and fix something, get it closer to that 100%. Do enough of this and you'll start to get a feel for it similar to the kind of rush you get when you're starting, only it is then associated with getting closer to the finish line instead of how far you got from the starting line.

It helps to pick small projects in the beginning to not lose sight of the goal.

Amadiro• 14 years ago

"The finisher" sounds like a mythical creature to me...

jblake• 14 years ago

I value the ownership of a project so much - the idea that when it becomes big, I can say, "I made that." Like the British guy who fought WWII with a sword and claymore. Challenge is rewarding.

Also, reading the Fountainhead was a game changer for me.

chaostheory• 14 years ago

Depending on the programming language, I can't help but feel that this article is out of date.

Today you don't really need to be a pure starter or architect anymore. There are so many frameworks that mimic Rails and its philosophy of convention over configuration, that there's not really a lot of effort needed to start and its easy to delegate most of the architectural duties to the framework developers themselves.

As for the debugger and finisher, that is also a lot easier as well. With all the automated integration and behavior driven test frameworks, it's relatively easy to both cross your t's and dot your i's. Today you can have something yelling at you everything second your tests break (assuming that you wrote them, which is key to any project).

dennisgorelik• 14 years ago

Debugging the code that you wrote for weeks on end isn't as satisfying as helping someone squash a bug in their code.

Most likely explanation is not boredom of keeping working on the same project from start to finish.

Most likely explanation is boredom from working alone.

ilaksh• 14 years ago

I think the actual explanation is this:

1) Generally managers still don't understand the concept of agile and early release and so try to cram as many features, bug fixes amd details into each release as they can think of.

2) There is no possible way that one programmer can take care of all of the bugs, extraneous little features and tasks that the manager was able to think of.

3) Therefore the manager must come up with a division of labor and a simple categorization such as suggested by this article is one of most obvious and is probably attractive to a lot of senior developers because it means they don't have to worry about as many tedious tasks which they know are unlikely to provide real business value.

I think that most programmers with a decent amount of experience don't really fit into any particular one of those boxes because they have done all of those things themselves for one or more projects.

andrewflnr• 14 years ago

I'm such a Starter/Architect it's not even funny. I know I need to work on finishing, but I can't fight nature (edit: I should say, I can only fight it so far).

Is there somewhere I can write to get a better Debugger/Finisher?

malkia• 14 years ago

The 4 seasons.

The Starter, the Architect, the Debugger and the Finisher

Related Stories