How architecture and the constraints that apply to it cannot be seen as separate things

In a previous project, I observed a typical communication mismatch. One team was demonstrating the technical details of architecture that, on first glance, was supposed to be a replacement for an existing architecture. The team demonstrated all kinds of technical solutions and showed us how much better they were than the solutions in the prior architecture. At some point the team compared a very nice and elegant implementation detail with the worst the existing architecture had to offer.

On itself, the new architecture contained some brilliant ideas that the old team wished they had thought of themselves. The point however, is that the team forgot to mention how different the constraints were under which both architectures evolved. By doing so, a lot of people in the room interpreted this as bashing the old stuff. And that’s a shame, because the old team could learn a lot from the fresh ideas the new team showed them.

The original architecture started almost five years prior to this meeting with best intentions. However, over those years the architecture accumulated technical debt, even though the old team keep tight control on it. Commercial pressure is a reality and forces you to take shortcuts and usually doesn’t give you enough room to pay pack on that technical debt…