I do not want this journal to show only the good parts
If I only write about new features, it will look as if Culture Atlas moves forward in a straight line.
It does not.
In September, we did a detailed check of the code and found a basic problem: the project could not make a proper production build.
A production build is the version of the code prepared to become the real website. It was a bit like finishing a model for a school exhibition and then discovering it could not fit through the classroom door.
Several small problems can become one big problem
There was not one giant piece of broken code. Some files were looking for the database connection in the wrong place. Some lists had not been updated when new types of cultural records were added. There was also old code that was no longer needed.
Each problem looked small. Together, they stopped the project from building. After they were fixed, the code checks and production build passed again.
Growing created another problem
Culture Atlas had grown in pieces. New kinds of records had been added, but not every older part of the website knew about them.
I started to understand why people talk so much about keeping code organised. When a project is tiny, I can remember where everything is. When it grows, the system needs rules so one change does not quietly leave five other parts behind.
My new rules are simpler than the technical words
Have one main way to connect to the database.
Have one main search system.
Keep one main list of the kinds of records Culture Atlas understands.
Do not call something “empty” if it may actually be broken.
After changing the code, check that the whole project can still build.
Can a computer catch some mistakes for me?
This led me to automated tests.
An automated test is basically a question the computer is told to ask the code again and again. For example: does every kind of Culture Atlas record have the information the system expects? If a relationship request fails, does the code notice?
The project now has some of these tests. They do not prove that everything is perfect, but they can catch certain mistakes much faster than waiting for me to find them while clicking around.
Permissions are like keys
Another check found that some newer database tables needed better rules for who could edit them. Those rules were fixed.
I think of database permissions like keys. A visitor may have a key that lets them read published information. An editor needs a different key to change something. The database should not simply trust anyone who asks.
A successful build is not the same as a correct product
Fixing the production build was necessary, but a green build only tells me that the software can be assembled. It does not prove that the cultural information is correct, the permissions are safe, or the experience makes sense.
I need different checks for different kinds of failure instead of treating one technical success as proof that everything works.
Checking the answer matters
In maths, getting an answer is not always the end; I can substitute, estimate or use another method to see whether it makes sense. I need that habit in Culture Atlas too. A successful build checks one thing. Source review checks another. Permissions check another. User testing checks something else. One green result cannot stand in for all the other checks.
Different failures need different checks
I used to think progress meant adding something new.
Now I think progress can also mean finding something weak and making it dependable.
The map and stories are the exciting parts people will see. Builds, tests and permissions are mostly invisible. But without them, the visible parts become much harder to trust.
Why I am writing about a failure
Because it happened.
I want this journal to show what building actually feels like: I make something, test it, find a problem, understand it better and change it.
What I'm figuring out next
Now I want to use the Atlas itself to find research problems. Which records are sitting alone? Which ones have only one or two connections? Which claims need stronger sources?
The database can help me notice what I still do not know.