Architecture Freeze

Some time ago I had an occasion to talk with my former colleagues from my previous company. They were talking how the team had changed, how the design and development processes had been altered. It was very insightful discussion for me. I learned that development team, which formerly worked under one manager, was split into two teams: one responsible just for architecture and tools and another working on functionality.

The architecture team have creative and clever guy as a boss, however he lacks experience in working on the software with business background, with real customers, real deadlines, real budgets etc. On the other side the functionality team have very experienced designer as a leader. Unfortunately he has no development background so he’s no partner in discussion for the architecture guy.

While I don’t say this kind of organization is generally bad, in this case, with these people, the split wasn’t the best idea. Architecture team ended up making constant, of course cool, improvements within base of code everyone else was using. In this case improvements sometimes meant complete redesign of major parts of architecture. Changes were implemented whenever architecture team was ready with them – in the middle of a new version development cycle for example. Yes, you’re right. That exactly means that functional guys had to rewrite big pieces of their code. A couple of times actually. Yes, you’re right. They weren’t happy with that. And yes, you’re right once again. It ended up with silent conflict between architecture and functionality groups.

I’m no longer the part of the team and I know the story in the way it was told me, although I was talking with people from both teams, so I guess I’m not very biased. However the idea of rewriting (oh, actually improving) architecture during every single version sounds for me hm... let’s say unreasonable. Approval for implementation this kind of things sounds even more... unreasonable.

OK, there is time for working on architecture. You should exploit it learning, brainstorming, prototyping, testing, verifying etc. You can start form a scratch again and again when you reach a dead-end, as far as you still have a time for that. That’s perfectly OK. It’s showtime for architecture guys. But then the architecture should be frozen. I know it isn’t perfect. That’s as clear as a day. But I know it won’t ever be perfect. That’s even clearer. Architecture freeze is essential when you start building functionality. It’s essential when you develop your application iteratively. While building a house you just don’t change you foundation when the walls are ready and you’re working on the roof of the building, right? So is with the software.

I don’t say you can’t touch the architecture. Some slight changes can be done, but you have to remember that walls are already there and one false move can ruin whole construction. Unless you have a lot of time and money to rebuild the whole thing (I envy you then), be careful