My top ten list on how to succeed with large projects. (5)

If you lose the map you're lost

Have you ever been in a project where the developers lost the big picture? It is tough to get back from.

If the map, the architectural blueprints, are lost it is like a disease out of control. The quality goes quickly from so-so to non-existing. People begin to duplicate code instead of using existing mechanisms, they put methods in other classes than they logically belong to and the cohesion gets more and more strongly coupled when the developers skip the architecture and shoots from the hip. And with bad code, unhappy coders.

The software architecture is more than just how the system was envisioned once in the beginning of the project. 

It is a guideline that should be kept alive throughout the project. It is the language of the project.

The architecture should continually be communicated throughout the project. A social gathering just as important as the scrum meetings or the project meetings. Focus on what should be where and how to reuse existing code. Focus on black box issues, code discussions beyond the classes and their interfaces are less helpful. As a developer I don't really care how a method is constructed as long as it accepts the arguments I want to change and do what I want it to do. Don't get stuck in details. I have seen too many projects where the  discussions is more about using tabs or spaces for indenting than entities. 

So to summarize: I propose an overview of the architecture every monday morning at 09:00! Keep the map alive!