Jacques Mattheij

Technology, Coding and Business

The Starter, the Architect, the Debugger and the Finisher

It could easily be the title of a Peter Greenaway movie.

Every software project that is remotely successful needs all four of these. If you can embody all of them in one person in the same project then all I can say is ‘lucky you’. But over the years I’ve found that depending on the project that can be four or more people. I know people that are great at starting projects, they are always on to something new and great. But it’s not the same ‘new and great’ thing they were doing last week, they already lost interest because the ‘hard’ parts are finished and so they’ve moved on to the next challenge.

Never mind that nothing ever gets finished that way!

Then there is the architect. Definitely not a person to get dirty hands from dealing with the implementation of the lofty goals laid down in design specifications. At least 3 levels removed from any production problems.

The debugger couldn’t be paid enough money to start from a blank page in order to get something new started. But throw him or her a hard-to-fix bug that has already stumped half the company and sure enough the fire starts to burn and the lights will be on at the office until the bug is squashed, no matter what it takes.

And finally, the finisher. The person that crosses every t and dots every i in order to get the last 10% (or is that 90?) of a project done.

Of course there are many other disciplines (such as user interface design) involved in a successful software project but when we’re just looking at the code it seems you need all of the above.

I find that when I look at myself that I can be any of the above, but rarely all four within the same project. For some reason when you’re the same person that started the project finishing it isn’t nearly as much fun. Debugging the code that you wrote for weeks on end isn’t as satisfying as helping someone squash a bug in their code.

The more roles I have in a project the harder it gets to perform all of them equally well. I wished there was a solution for this but I haven’t found it yet. At least I’m lucky enough that I can perform all these roles, even if it is in different projects but I wished there was a way to get a more level performance across all of these roles within the same project.

That would make life a whole lot easier. I think part of this is a stamina problem, after you’ve been working on the same code base for an X number of months or even years it gets harder to find the motivation to keep going to the end. Part of it is that debugging requires endless patience and the longer a project runs the harder the bugs will be (that’s pretty typical, after all the easy ones have all been found!).

So I try to avoid those projects where I have to wear too many hats, in start-up situations this is unavoidable but to maintain an even flow and a more or less constant throughput it is much easier to divide these roles across a few people. It gives opportunities for criticism and it helps to break deadlocks and to overcome a lack of motivation. Working on your own it is very easy to end up ‘just’ being a starter, to create a hundred half baked projects which go nowhere. But as soon as you work with others there is more energy in the system. You can power through the easy and fresh phase into a more mature project by dividing the tasks and by assigning a quality control role to the next person ‘downstream’.

Which greatly increases the chance of actually finishing a project and getting a return on the investment in time!