Building a Website for Green Club
Decide how to decide
The Green Club at school needed a website, so I volunteered to build one. It seemed like a nice way to be useful. Easy enough.
I quickly learned that you cannot build a website out of nothing. Before anything actually gets made, you have to pick the tools you are going to use to make it. So without realising it, the first thing I did wasn't building a website at all. It was trying to choose a platform to build one on.
My first instinct was to go for the fun part. The first platform I thought about using was Vercel. A friend had told me you could push your own code and have a live website within minutes, which sounded exciting until I started thinking about who would maintain it after I was gone, at which point the excitement cooled noticeably. So I kept looking. Then Wix. Then Notion. That evening I alternated between the tabs I had open and made absolutely no progress, picking one platform over another and then endlessly justifying my choice. I was losing a battle with myself, which is the most annoying kind of battle to lose.
I had quietly jumped from "build a website" to "choose a platform" without noticing, and then it went a rung deeper. The problem wasn't picking a platform. The problem was that I had no rules for picking a platform. I was choosing based on whichever option looked nicest to me ten minutes ago. Then a slightly unpleasant thought came to me. Picking a platform is work. It is an actual task, just like building the site, or writing, or anything else. And task work cannot be done on gut feeling. There has to be a process. So the first task wasn't deciding which website-building tool to use. The first task was deciding how I was going to decide which website-building tool to use. I had to build a process, then run the process, then decide.
What got me there was, of all things, curiosity. I had hit a dead end and figured: people build software for a living, surely they have a better way of choosing software than I do. So I looked it up. It turns out professional software engineers have a very dry, very structured way of making decisions, and they actually write the reasoning down beforehand. The format even has a name. An ADR, short for Architecture Decision Record. I borrowed the system.
The funny moment came when I started writing my first one. I was using the ADR format, and when I got to the "A" for "architecture," I had to pause. I wasn't designing any software. I was choosing a way to decide. I almost gave up on the format right there, until I realised that what I was choosing was architecture, just not software architecture. A method is a way of structuring how a team works and decides. That is organisational architecture. So it actually belonged in an ADR. This became ADR-1: the method itself.
The method I landed on had two steps. First, score every option against a set of hard criteria and throw out anything that fails any of them. No exceptions, no special cases, no rescuing your favourite option just because you like it. Then take what is left, and score those options against what each team member weights as most important. The second pass makes sure that a small win on something genuinely important doesn't get cancelled out by a small win on something trivial.
The process forced me to be honest with myself about who I was actually building the website for. I will be graduating in two years.
The people who will come after me to update the site, to post events and announcements, are not programmers and won't be. The only person who could realistically deal with a technical problem on the site is me, and I will not be there. Engineers have a slightly dark term for this sort of situation, the "bus factor." How many people would have to be hit by a bus before the project is abandoned? Mine was one. Me.
Only one thing defeated my first choice. I wanted to build something impressive. Something custom-coded, fast, and showcase-worthy. I could have built it. But once I was honest with myself that I would be the only person on Earth able to maintain it, it failed one of my own criteria, and I had to drop it. No matter how much I liked the idea.
The options I had been least excited about were the ones that remained. I scored them, and the clear winner was Google Sites. By far the least exciting option on my original list. The right answer was the boring one. That frustrated me for about a day. Then it stopped frustrating me, because I understood why. A website that goes dead the moment its one technical person leaves isn't a better website. It is a worse website that happens to be clever.
Looking back, the choosing itself had two distinct steps rather than one. Step one was choosing the method. Decide how I would decide, then write it down. That became ADR-1. Step two was the actual choosing. Run the method, score the options, write down the outcome. That became ADR-2. Only after both of those steps did I actually open a browser and start building.
The detour cost me about two evenings I had set aside for coding. They were two of the most useful evenings of the whole project, and I don't think that had very much to do with the website itself. It was the first time I caught myself falling in love with the most complicated option, mid-fall. Before this, I had been optimising for what would impress people, and what would impress me, rather than what would actually be useful for the club after I was gone.
So I ended up with two of these records. ADR-1 contained the method, the rules I would use to choose. ADR-2 was the result of actually applying the method, written up the same way. Two steps of work, two records. I like that they exist. They show that the choice wasn't made impulsively, and they leave a note for whoever inherits the site about why it is the way it is. They are included below, in all their boring formatting.
Architecture Decision Records: