Promoting good design vs policing a good design
On a project with a small co-located existing team, the team can work as a harmonised unit to produce code that adheres to good design prinicples. This does not say that large distributed teams can not also produce similar results. What it highlights are the following assumptions in a small co-located existing team:
However, projects grow and there is natural nutrition of members to teams. Expecting everyone to know everything becomes more difficult. Furthermore, expecting everyone to adhere to architectures and designs by members possibly no longer on the project becomes even more difficult. Overtime the project moves away from its origins. This by no means is a bad thing and many methodologies expect this change as it is natural change resulting from changing business requirements.
What is an issue is decisions being made without understanding the context in which the decision is being made. It is all to easy to blame a developer for making a change that negatively impacts the system. It is much harder to provide the necessary information to a developer to aid them in making good decisions. Typically, through budget constraints or even some software methodologies, the developer is given code files, some configuration files and with the aid of another developer who can only provide them limited time (as they themselves have functionality to deliver), the developer is expected to understand the application and then start producing functionality.
What results is the developer making changes to the internals of the application and these changes require 'policing' to ensure they align with the application's goals. As information about a system is typically only in the thousands/millions of lines of code/configuration (with other artifacts either stale or non-existant), the developer can only realistically pick up limited information about the application and therefore must make changes based on this limited information. The developer must be managed ('policed') to ensure that the changes do not conflict with the goals of the application.
In managing developers the rate of change by developers makes management a potentially costly process. Code reviews are important processes of any software development lifecycle, however reviewing code can be quite tedious due to the detail it encompasses. It also encourages focus on 'code style' rather than the underlying design principles that produce a well designed system. The focus of good design starts getting lost in all the detail that must be understood by everyone involved.
Good design sees pasts the details of the code to the underlying principles of the application. In architecting/designing applications it is typical to use some form of graphical abstraction (eg UML diagrams) to specify the various aspects of the applications. This allows discussions at various levels of abstraction about the architecture/design of applications without being caught up in the details of the code.
The developer needs to be able to discuss the application at the right level of detail so they can learn quickly what is necessary to make their changes. Rather than having to 'hack' around to make necessary functionality changes, the developer can use these graphical abstractions to gain an overview of the system and isolate the necessary aspects involved for their changes. The developer then need not be overwhelmed by the entire details of a system, and can use this information as an understandable context for making good decisions.
OfficeFloor provides these graphical abstractions through its graphical configuration allowing developers to more easily understand the design principles of the application and see how the functionality of the system is put together. In essense, it provides developers the necessary information and context to make good decisions.