A couple of months ago I had the possibility to talk to the CTO of a local company about hiring decisions. He told me, that given the choice between hiring a bricklayer whose goal is to feed his family and one whose goal is to build a cathedral, one should always hire the cathedral guy. Funnily the man went on to show me two pieces of hardware, one that was obviously completely overengineered and one that would do what was required (but not a wee bit more), telling me, that the second design is clearly superior and that he wanted all designs of his department to do designs that are more like the second design and less like the first one. That did not strike me as odd at the time, much less in direct contradiction to the brick layer story. However last week I got to think about the episode again and, well: The two PCBs were essentially the equivalent of a cathedral and a plain wall. Luckily – the guy himself was also oblivious of this striking contradiction.
So, what’s wrong with wanting to build cathedrals?
Glad you ask. Nothing really, if, what you want to build, is actually a cathedral. If not you might be in for a world of pain (and costs, quite frankly). Someone who wants to build a cathedral but is tasked to build a home for a family of four might be tempted to sneak in little things to get his/her kick, whereas the guy who’s not in it for doing humanity inspring work is likely to do as he’s told and create a decent piece of work altogether.
Wait, isn’t this blog about software?
Absolutely, and you probably guessed the whole Cathedral vs. Family Home thing is a metaphor on how different people approach software engineering. There are those who want to create a pure architecture, that is a work of art, and there are those who want to get the job done. In most projects you’ll need both kinds of people (or, ideally people that can switch between the two “modes”) – the cathedral builders are the people who are responsible for advancing the state of the art (are what counts as that in your company), whereas the others will make sure the projects actually get finished at all. People who are only suitable for one of the two modes are capable of doing a lot of damage to your product:
- A cathedral builder let loose will get lost in refactoring and building ever more complex architectures and will find it hard to complete the project.
- A “home builder” tends to only ever build the most obvious solutions for a given problem with little regard for future maintenance or evolvability.
- Cathedral builders tend to produce more bugs (that is probably the price of being on the bleeding edge).
- Cathedral builders are more likely to suffer from the “not invented here” syndrome.
Who should I hire then?
I’ll give you a sounding “it depends”…
- How is the balance between the two types on your team? You’ll absolutely want to have both archetypes of developers, however as a rough estimate I’d argue, that your team should be predominantly composed of “home builders” for most projects, maybe 3 “home builders” for each “cathedral builder”.
- What kind of projects do you expect? For run-of-the-mill projects with few unknowns you can have teams that only consist of the “home builder” archetype.
- Complex projects, where the requirements are not yet clearly understood and/or projects that touch new technologies (at least new for your company!) benefit tremendously from having cathedral builders on their teams, be wary of composing teams only from cathedral builders, as it’s hard to get them to develop a shared vision.
So, cathedral builders are somewhat bad, right?
No. However they’ll never be content with solutions that have already been built and they’ll always try to push the envelope a little further. This can be very tiresome but it will usually pay off in the long run. Having no cathedral builders will cause stagnation.
Is this a binary thing?
No, the two mentioned characteristics are archetypes and most developers will not be one of the two 100% of the time. Treat this as a spectrum, where each person may tend towards one or the other extreme depending on their personality and on the situation at hand. The latter is important to know, especially since this is hard to gauge during an interview.