Recap
In Part 1 we wrote an engineering brief for a batch image processor and built a first version that resized photos, made thumbnails and recorded everything in a database.
Scope creep has a terrible reputation, and mostly it’s earned. Features get added one at a time, nobody decides anything, and eventually the project is a different animal from the one anybody approved.
Ours did exactly that. The batch processor became a gallery. What we did differently is that every addition was a decision, and every decision was written down.
The path from tool to gallery
The growth happened in stages, each one a sensible reaction to the last:
- The processor recorded photos in a database, so we added a second admin page to organise them into albums and add captions.
- Albums needed to be viewed, so we added a public page, read-only, so visitors could browse without being able to change anything.
- Big libraries needed paging and a smooth viewer, so we added pagination, a lightbox, and deep links so a single photo can be shared by address.
- Owners wanted to say something about their gallery, so we added two small text fields, one for a welcome note and one for a photographer credit.
The result is two admin pages, one for processing and one for organising, plus a public gallery for visitors. Each stage was small enough to build and understand before the next began.
Include, reject, roll back
The discipline was in how we handled each idea. Every proposal went into an improvements plan, and each got one of three answers.
Include. Longer cache lifetimes for images were an easy yes: free speed for returning visitors, at almost no cost in complexity.
Reject. A proposal to generate larger thumbnails for sharper grids was turned down. It sounds attractive until you picture someone opening the gallery on a phone over a mobile connection. Bigger thumbnails mean a heavier first load, and the first load is the one that matters. We recorded the rejection and the reason, so the question wouldn’t be reopened by accident later.
Roll back or reshape. Some ideas were accepted in a different form from the one first proposed. The “landing page” idea is a good example. Rather than an always-on front page, we settled on something deliberately restrained: a starter album, capped at four images, which becomes the homepage only if the owner puts something in it. Leave it empty and the site stays quiet until a visitor picks an album.
That restraint was a design opinion, not an oversight. The gallery is meant to show little until somebody chooses to look, because photos left out in the open tend to get taken.
Why write the rejections down
Recording what you declined is more valuable than it looks. A rejected idea comes back, usually from a well-meaning person who has just thought of it for the first time. If the reason is written down, the conversation takes thirty seconds.
It also works on the AI. An assistant that is asked to “improve the gallery” will cheerfully re-propose things you already turned down. A plan that lists them, with reasons, is something you can point it at.
The plan as a safety rail
The improvements plan did two jobs. It stopped good ideas from being lost, and it stopped bad ideas from sneaking in. When the plan was finished it was frozen: kept as a historical record of why things are the way they are, and never edited again.
In short
scope creep turned a batch tool into a full gallery, but each step was a written decision to include, reject or reshape. The plan kept the growth deliberate.
Read next: Working with an AI that writes the code.
Leave a Reply