To get a deeper understanding of a concept we need to detach. To step away and find a new angle of observation. It’s surprising how much we can learn about software this way, through connections that weren’t obvious at first. One such link is between software design and construction work.
I recently bought a house and the amount of small, seemingly insignificant details that you have to think over is amazing. The power outlets, the lights, the tiles - everything mattered. Even the placement of the TV, so you could stream something while washing the dishes.
Looking at the construction industry, where every inch mattered, I wondered whether I put enough attention to my craft. I had accepted that refactoring and rewriting are an inevitable part of the software development process. So why fret the details?
Too often we rush to build and create. Without constraints or design. The application’s architecture develops as we go. But if a construction worker came and started laying bricks without a detailed plan, I wouldn’t call it agile, I would call it madness.
In its essence, a house is a large square-shaped structure. But its insides can be arranged in countless creative ways. The same way, a service comes down to an endpoint that returns JSON (most often), but its architecture can vary.
It’s not just a matter of logic and physics but of creativity and beauty. In a house you’d want a nice view from the bedroom, a well-equipped kitchen and a spacious living room. Maybe a porch where you can watch the sunset with a loved one.
When building software, we can put all our components in a single file. But we don’t. Because we want to establish clear boundaries and responsibilities. We want an application made of modules that interface and communicate through established rules. We want to make modifications with little impact or extend and grow the product. We want it to be testable and predictable.
But most of all, we want a pleasurable and productive development experience. We want to create constraints but still allow every team member to do creative work, not just manage tech debt.
Beauty and productivity aside, software design is about fighting complexity. Clear variable names reduce obscurity. Generic functions and abstractions improve reusability. Hiding complexity in modules or classes improves simplicity.
Anyone can build a software product and leave it behind. But creating something that needs to be extended and modified requires thought and care. Focusing on software design makes us go through the architectural problems in advance so we don’t have to tackle them without preparation. Good architecture doesn’t happen by accident, it requires deliberate thought and action.
Is this only important for us, the developers? No it’s important for the product and the business.
Successful software projects have long lives. They change and evolve. If an application’s architecture doesn’t support that, product development will suffer. Developers will struggle, looking for workarounds and take massive amounts of tech debt for each new feature.
How we build is as important as what we build.
