Why the World keeps changing

The careful path

The first approach is to test exhaustively and release rarely. A change might be specified, reviewed, implemented, tested against thousands of cases, and then tested again by people who did not write it. After all that, it waits for a release window months away. Nothing ships alone, and everything ships together, once, after everyone has signed their name to it.

This sounds slow because it is slow. That is the point. It is the correct way to build software when a change cannot be taken back. Think of flight control systems, where a fault has nowhere to land. Or a pacemaker, where the software is inside someone. In those worlds a year of validation to change one behaviour is not bureaucracy. It is proportionate, and anyone building them should be held to exactly that standard.

The cost is that the software stops being able to respond. A good idea raised in January arrives in December, if it arrives at all. That is a trade worth making when the stakes demand it. It is a strange trade to make for a puzzle site.

We went the other way

Our approach is to make changes small, ship them quickly, and keep shipping. When someone suggests something that makes sense, the goal is to have it live in days or weeks rather than filed away for a release cycle that may never come. When something could be better, the goal is to improve it and push the improvement, not to schedule it.

We would rather run a site that is visibly moving than one that is impressively still.

A static site is finished, and a finished site slowly becomes a worse version of itself as the world moves around it. A dynamic site is never quite finished, which is uncomfortable to say out loud and, we think, the right way round. The games you play in a year should be better than the ones you play today, and that only happens if the site is allowed to keep changing.

Small releases help in a way that is easy to miss. When a deployment contains one change, we know exactly what it did. When it contains sixty, we have an investigation on our hands. Shipping often is not only quicker. It makes everything easier to understand.

The two approaches, side by side

Test heavily, release rarely. Months or years between releases. An idea raised today lands a full cycle away, and feedback waits for the next window. This is the right answer for systems where a fault cannot be undone.

Improve continually. Days or weeks between releases. An idea raised today can often land the same month, and responding to feedback is part of an ordinary week. This is the right answer for systems that should keep getting better.

Neither one is the wrong answer. They are answers to different questions, and a puzzle site is squarely the second question.

The work behind moving quickly

Choosing to move quickly is not the same as choosing to be careless. It only works if the things underneath it are boring and reliable, so a fair amount of the work here goes into exactly that.

A separate environment. Changes go to a testing environment first, isolated from the live site with its own data. Nothing reaches you having only ever run on a laptop.

Automated checks on every change. Tests run each time code is submitted, and a failing test stops the deployment rather than warning us about it afterwards.

Every release is identifiable, and we can go back. Each deployment is stamped with a version, so we can always tell exactly what changed and when. Because releases are small and versioned, undoing one is a routine action rather than an emergency.

Your data is protected separately. Databases are configured with point-in-time recovery and deletion protection, so the safety of your history does not depend on the code around it.

Bigger changes get a window. When something substantial needs to go out, we can announce a maintenance window in advance and make the change with nobody mid-game.

No amount of testing catches quite everything, and a site that changes often will occasionally need a quick correction. We plan for that rather than hope against it. It is why the tooling above exists, and why Report an Issue in the menu comes straight to us. It is genuinely useful, and it is read.

Which makes you part of it

The reason to build this way is that it lets the site be shaped by the people using it. A suggestion that makes sense can become part of the World shortly after it is made, rather than joining a list nobody revisits.

We won't promise that every idea gets built. Some conflict with others, some would make the games worse, and some are simply more work than they are worth. But every one gets read, and the ones that make sense get built as soon as we can manage it.

That is the trade we have made, and we think it is the right one for a place people visit for a few minutes a day to play games. It also means the site you use next month should be a little better than the one you are using now, which is rather the point.