The Hidden Cost of Change

When I first started writing my own PHP applications, every project was self-contained.

That seemed like a sensible approach. Each application lived in its own directory, had its own configuration files, its own navigation, its own page layout and its own collection of helper functions. There were no dependencies between projects, and that meant I could develop each one independently.

For a while, that worked perfectly.

The problem wasn't building new applications.

The problem was changing existing ones.

Imagine deciding that your website header needs redesigning. Perhaps you want to add a search box, change the navigation or update your branding.

With a single application, that's a straightforward task.

With ten independent applications, it becomes ten separate tasks.

Every header had to be updated.

Every footer had to be updated.

Every navigation menu had to be updated.

Every configuration change had to be copied into every project.

Every bug fix had to be repeated.

None of these jobs were particularly difficult. They were simply repetitive.

Over time I realised that I was spending less time writing new features and more time making the same change in multiple places. The applications themselves weren't becoming harder to understand; they were becoming harder to maintain.

The more projects I created, the worse the problem became.

Ironically, this wasn't caused by poor programming. Most of the duplicated code had started life as perfectly reasonable solutions to individual problems. The issue was that each project solved those problems independently, even though they were fundamentally the same problem.

That was the moment I began to appreciate the difference between writing software and designing software.

Writing software is about making something work.

Designing software is about making future change inexpensive.

I didn't immediately set out to build a framework. Instead, I started asking a much simpler question.

"Why am I maintaining ten copies of the same code?"

That question changed everything.

The obvious answer wasn't to become more disciplined about copying changes between projects. It was to stop needing to copy them at all.

If every application shared the same header, there would only be one header to maintain.

If every application shared the same navigation, there would only be one navigation menu.

If every application shared the same configuration, there would only be one place to change it.

Those ideas seem obvious in hindsight, but they only became obvious because I'd experienced the pain of doing things the other way.

The framework didn't begin with a grand design document.

It began with a desire to stop making the same change over and over again.

Looking back, I think that's how many good architectures are born. Not from trying to create something clever, but from removing unnecessary repetition until the remaining structure simply makes sense.