The Architect Model

I first became familiar with the idea of a "Software Architect" after reading Frederick P. Brooks' seminal classic, The Mythical Man Month. I read that book, on recommendation from one of my professors, pretty early in my programming career and it has done quite a lot to direct what I currently am as a programmer. To anybody who hasn't read it yet, I highly recommend it.

The idea behind having a single architect in a system is to maintain integrity and unity of vision, and prevent the dreaded "design by committee" that plagues so many projects. A project, in order to succeed in a sea of thousands of other projects, must do one thing and do it well. There must be name recognition, clear association between product and purpose: If you are looking for a good robust webserver, you think Apache or one of it's relations. If you want a good C# IDE, you think about Visual Studio. If you want a solid dynamic language-agnostic virtual machine, you think Parrot (at least, I hope you do!). These associations pop up because these projects do one thing and do it well, and when you have that one problem you know exactly where to find a solution for it.

Parrot could readily be extended to do more then it currently does: it could be more targeted towards static programming languages like C, C++, Fortran, and Java. Maybe it could support both stack- and register-based operations for easier translation from other virtual machines that are stack-based. Maybe it could natively interpreter CLI and Java bytecode formats, as well as PBC. Maybe we could create a huge general-purpose repository of runtime libraries for all of our users to tap into. Parrot could be made to do a lot of things that it doesn't currently do and isn't intended to do. But adding these things would water down the vision and remove the kinds of opportunities that a focused specialization bring. Do one thing and do it well. Very well. There's no benefit to doing a bunch of things poorly.

Parrot has a chief architect, Allison Randal. In the general sense, her job is to maintain that unified vision, to see things from a much higher level then the code monkeys like me see from our place in the trenches. This is not to say that myself or the many other committers are not empowered to make decisions in implementing the high-level designs, or that we are not empowered to make those designs ourselves. In fact, from what I have seen about Parrot there is no real point in the process where Allison must be involved. I could design a new system from scratch, implement that system, and commit my changes to trunk. Assuming my work is sane and nobody complains about it, that would just be the end.

The real benefit to having a dedicated architect like Allison, or a knowledgeable senior programmer like chromatic, is that we have a great sounding board for ideas. It's not just about getting my code committed to Parrot, it's about having the right code committed. My solution may indeed work for the cases I've considered, but will it be the right thing for Parrot in the future? Will it have to be ripped out or refactored later when new use cases are found? Will people years from now be looking at it and saying "That Whiteknight guy sure wrote some lousy code here!"? Will it be what our end-users need it to be?

I can find a solution, think about a few ideas and--before wasting any effort on a potential implementation--I can run them past Allison to pick the one that is best for the project in the long run. On more then one occasion I've presented her with two decent solutions to a problem and she's countered with a third option that I had never even considered, which is far better. Each time we have a discussion like this I can be more confident that the solution I implement will be a good one, I grow and improve as a developer, and I learn a little bit more about the overall design vision for Parrot. Next time around my work will be more informed.

I've known a lot of programmers, at school and at work, that were very good at what they did but who did not share there knowledge or their expertise. There are strong feelings of ownership and secrecy. Strong undercurrents of competition, including hostile competition, between team members. It's not until you join a project like Parrot that doesn't have these things that you realize how much of a huge waste and mistake they are. The best programmers aren't those who toil in solitude and produce code that "just works". The best programmers are the ones who share their skills and learn freely from the skills of others, and who actively try to improve themselves and their team.

We run into situations on occasion where it starts to feel like "us versus her", the lay-developers versus Architect Allison. I worry about these situations, and I try to avoid or diffuse them where possible. We always want what Allison wants: a better Parrot. I've found in my experience that she usually has the best understanding of what that means. It's better to work with her then it is to work against her, even if both paths lead to committed code and fixed problems.

Three days ago we were talking on IRC about the ongoing PCC refactors, and talk turned to how long we were going to have to wait for Allison to finish them. They have been a long time coming, and other developers are starting to become blocked waiting for these particular improvements to land. This combined with a sense that Allison had ownership of the branch where changes were happening and that she alone really knew what needed to be done to resolve things, created a feeling of helplessness. If you read through that IRC log you'll see what I mean: several very talented, capable developers are taking a very passive wait-and-see attitude towards these necessary refactors, when the team of them combined could likely have all outstanding test failures resolved in days, if not hours. We have an extremely talented and capable team working on Parrot, I really can't stress that point enough.

I decided that we shouldn't be waiting for Allison, we should be helping her. She had a really great design, what was needed were a set of hands to jump in and make it real:

I don't think that only allison can work on it. If we put together a little strike team, I think a group of us could fix it up pretty quickly. ... I say that's the new plan: create a copy of the branch and everybody who is blocking on it can get their coding asses in there to fix it

Allison joined the discussion shortly thereafter and, in characteristic fashion, got things moving:

so, here's the plan, anybody who's interested have a look at the code in the next few days. While I'm on the plane, I'll write up a high-level description of how the new PCC is *supposed* to work. (understanding that seems to be the biggest blocker for people getting involved). I'll prepare a list of tasks that need to be done, so they can be distributed.

On IRC for less then 5 minutes and we have a plan to get the problem solved: Combine Allison's design and know-how with our development team's talent and tuits, and everybody wins. This morning, Allison delivered on her promise. Work is already beginning in earnest following Allison's post.

I like the idea of an architect a lot more then I like the idea of a "Benevolent Dictator for Life". Being too reliant on one person in perpetuity always strikes me as a very fragile way to setup an organization. In contrast, there's no reason to suspect that Parrot would flounder if Allison left. Quite the contrary Parrot has been through several architects and has continued development strongly. There has also been some talk around about setting up other authority positions like sub-architects, lead developers, etc. I like that idea too. A rich meritocracy with people who are known to produce good code and good answers is a good thing. I don't have any particular opinions on which "offices" Parrot should have or who should fill them, but that's just me.

So that's my take on Parrot and the Architect. It's generally a good system and I like it, although we all need to keep in mind that "us with the architect" is better then "us against the architect".