Sunday, June 14, 2015

Architectures of a different type

My father-in-law is an architect -- the kind who designs buildings. He has been an architect for many years and he has worked on a wide variety of interesting projects, from dormitories at Harvard University to pump houses in New York state reservoirs.

As a software architect, I have always been fascinated by the kind of architect whose end product is something you can touch and feel. He's the kind of architect whose work you live in rather than one whose work you live with. I am an architect of the latter -- you have to live with what I do and my goal is to make that process simple, reliable and efficient.

As an architect of the abstract, I've always been curious about how things get designed and built in the tangible world. Building projects can be exceedingly complex and require a collection of many different types of skills, yet we have become pretty good at it. When a company starts to build a building, more often than not, the building gets finished. While it may be a little late or over budget, it gets done and it works like it's supposed to.

Software projects are far less reliable. I've read some articles that claim that most software projects fail. I've seen software projects get abandoned -- something that rarely happens midway through the construction of a new home or office tower.

So the question that comes to mind is this: Why?

Why is writing well-designed software seemingly harder to do than building a well-designed building?

Lately, my father-in-law has been grumbling a lot about the bureaucracy of building a building. He spends more time meeting with planning committees, seeking the approval of inspectors and providing government agencies with various impact reports than he does in the process of dreaming up the design or executing the plan.

On a recent evening, I was mulling this over and I came up with a few ideas for why we seem to be better at building buildings than we are at writing software:
  1. A building's architecture is designed before the process of building begins.
  2. Building architects have to design buildings according to building codes -- clearly defined standards of quality that can be measured and these plans must be approved before construction begins.
  3. The building is inspected by experts as it is being built.
I could keep going, but you get the picture. You would never start a building before the designs were done. You'd never just trust an architect's design; you'd want to make sure the design adhered to quality standards. Likewise, you wouldn't just trust the construction crew to do the right thing and build the building according to the design.

You wouldn't do any of these things with a building, but companies do this with software all of the time. But it's always a bad idea.

Software architects also have a similar set of tools at their disposal, and these tools should always be used:
  • Design patterns: these are the equivalent of building codes and standards. The human race has been writing software for a long time. We've learned a few things in the meantime. Design patterns encapsulate this knowledge into practical solutions.
  • Code reviews: code reviews are the inspections of the software development world. They can be performed by peers, or by managers of projects, but they should always be performed. No software should ever be deployed into a production environment that has not been reviewed by at least one other person.
  • Automated tests: all software development projects should have automated tests that demonstrate that the software does what it's supposed to do. This is another form of inspection -- it makes sure that the software still works, even when changes are made to it later.

No comments: