Evolutionary architecture and emergent design: Environmental considerations for design, Part 2
In The Pragmatic Programmer (see Resources), Dave Thomas and Andy Hunt borrow the concept of broken windows from studies about abandoned buildings. Deserted buildings generally aren't damaged until a window is broken. That first broken window indicates that no one cares about the property, and the general disrepair and abuse of the building accelerate thereafter.
Broken windows occur in software development too. When you see some code that's not technically a bug but isn't quite right from a design standpoint, you've found a broken window. Collective code ownership says that you must fix that code. Part of the reason that software projects tend to become more fragile and brittle over time is the presence of hundreds (or thousands) of broken windows. If you fix them routinely, your code can get stronger with age, not weaker.
My projects always use pair programming, and we're always on the lookout for broken windows. But we don't automatically drop what we're doing to attack those problems as soon as we find them. When my pair and I discover an error, we assess how long it will take to fix it. If it will consume less than 15 minutes, we'll go ahead and fix it inline with whatever other story we're working on. If the change is more involved, we add it to a technical-debt backlog. All my projects have a technical-debt backlog, maintained by the technical lead. When we get slack time on the project, the tech lead assigns stories from this backlog to eat away at accrued technical debt gradually.
Collaborative design also suggests that developers are responsible for the correctness and quality of the parts of the overall application they create. Correctness has two facets: adherence to the business requirements and technical suitability. Business-requirements correctness is determined by whatever verification mechanism your company ecosystem has in place to judge the software's suitability to the problem it was written to solve. Technical correctness is left to the development team.
Different teams put their own procedures and mechanisms in place to ensure technical quality, such as code reviews and automated metrics tools run via continuous integration. One practice that many agile teams employ that's a key enabler of emergent design is collective code ownership (http://www.martinfowler.com/bliki/CodeOwnership.html), which suggests that every person on the project has ownership responsibilities for all the code, not just the code he or she has written. (Another benefit of ... collective code ownership is bringing up everyone's skill level to that of the most skilled team member.)
More specifically, it requires:
* Frequent code reviews (or real-time code reviews such as pair programming) to make sure everyone is leveraging common idiomatic patterns and other useful design discoveries by the collective group.
* Awareness by everyone on the project of at least some of the details of all parts of the project.
* Willingness for anyone on the project to jump in and fix broken windows regardless of the original author(s) of the code.