What plastering my first wall taught me about software architecture

Title
What plastering my first wall taught me about software architecture

Body
Last week I plastered my first wall and made the mistake of doing it in halves.

I finished the bottom section first, then moved up and did the top. The join between them turned messy because the wall should have been done in one continuous pass. I then spent the next 2 days fixing rough areas with jointing compound and sanding.

What struck me was how architectural the mistake felt.

The wall did not really fail in the flat middle. It failed at the join. That felt very close to software architecture, where problems often show up first at boundaries:

• between old and new code
• between services
• between frontend and backend
• between the model and the workflow it is supposed to support

A few things stood out to me:

• The finish cannot rescue a weak layer underneath.
• Rework gets expensive fast once the next layer is already involved.
• Physical work gives immediate feedback. Software often delays it until integration or production.
• More effort is not always better effort if the sequencing is wrong.
• Cleanliness and discipline matter more than glamour.

That last point felt especially true architecturally. A lot of the work that keeps systems calm is not flashy: clear boundaries, clean environments, naming, predictable deployment, and not carrying old mistakes into the next layer.

I wrote a longer version here if anyone is interested:
https://nikoskatsikanis.com/blog/plastering-code

Curious whether other people have found the same thing: architecture problems often stay hidden in the middle, but edges and joins tell the truth first.