I regularly commute to a client’s site past a large hospital complex. The building consists of a series of wings, the first two of which are nearly identical and obviously were built at the same time. Two newer additions to the building sits beside them, each using an entirely different look and pattern. No reuse here.

It reminds me of growing up in Toronto back when there was only one terminal at its airport. When the terminal was built, the plans called for additional terminals to be built later using the same design. But that never happened. Three more terminals have been built since the first opened in 1964 all utilizing different designs.

No reuse here either.

So what is going on, and can we see any parallels to software architecture?

The technical answer is that requirements change. New wide-bodied jets made the round architecture of the first Toronto airport terminal inefficient, for instance. Perhaps new equipment or capabilities were required or new building materials became available that precluded the hospital from re-using its existing design. Perhaps.

But something else was surely going on here as well. Something that has stymied efforts over the years to develop re-usable software and the fabled software building blocks. Something called ego.

When a new team is brought in to build a new system, it can be guaranteed that they will not look at existing systems in place and recommend configuring or modifying one of them. Much more likely will be a total redevelopment using different technologies and patterns, mostly from the resumes of the new architects. There will be justifications around “not wanting to repeat past mistakes” (as the new team goes on to develop new and innovative mistakes), but the reality is that ego is a prime factor. No architect wants to come in and say “hey, let’s do what that guy did”. It doesn’t satisfy the itch to build something new. Nor does it justify the architect’s paycheque.

So what does this tell us?

1. For one thing, architects, designers and developers must remember that one imperfect design is better than multiple designs, no matter how perfect any of them night be. The long term cost of any software project is maintenance, and the maintainers will have no idea why two systems that seem to tackle the same problem are built in different ways.
2. Existing systems may have warts, but so will the new system. Known warts are cheaper than new and innovative ones.
3. On the other side of the coin, build a system for your requirements and don’t try to guess how it might be re-used. You will get it wrong anyway and create an overly complex and error-prone system. If you ever get a second client (which is less likely than you think), utilize this thing called “refactoring” to pull out generic concepts and make the system re-usable.

Architects and designers are people with egos. And people with egos always overplay their own ability and underplay other’s. Take a slice of humble pie and ask yourself “Could we reuse that other system? Would it be good enough”. If you decide to build a new system, don’t design for re-use until you have a second user.