Back in 1968, Melvin Conway stated that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations". This statement is still relevant today and is well known as the Conway’s Law.
There’s a lot of truth in this observation, and many organizations take this law seriously and structure their development organization to best reflect their desired architecture. The desired outcome of such organizational structure, which is mostly achieved, is that each component is cohesive, loosely-coupled from the other components, and also pretty well maintained by the team – due to the perception of ownership of each team on its code.
A common example is when teams are divided “horizontally”. I.e. a team for the UI, a team for the business logic and a team for the persistency/data access layer. This separation also has the advantage of building expertise in each of the technological areas.
However, when the teams are structured “horizontally”, mostly every feature and every change has to permeate through all the layers (which also means – all the teams). This causes each change to take longer to developer. It also makes these changes more bug-prone, and often creates duplication between the layers.
Even if the teams are structured differently, as long as each team has an exclusive responsibility for its own component, it has following drawbacks:
· It prevents knowledge from spreading to other teams and creates silos of knowledge
· It prevents developers from seeing the big picture and be more engaged in the business goals of the customer
Does agile solve it?
These drawbacks bring many Agile supporters to encourage cross-discipline “vertical” feature teams and avoid a strict code ownership. However, this also has drawbacks, especially in large projects:
· People with inappropriate skillset make changes to areas of code that they’re not fully understand
· Because there’s no “owner” for any piece of code, the quality of the code tends to deteriorate
· The overall architecture tends to deteriorate
So what can we do about it?
So are we forever doomed to make compromises about our quality and delivery pace (especially in large projects)? I don’t think so! I believe that few things can and should be done in order to keep both the pace and the quality high, without giving up on knowledge spreading and engaging the developers in the customer’s business goals:
1. Don’t give up on Agile. This is the basics that will allow us to keep a high pace, while improving knowledge sharing and ongoing improvements. However it’s not sufficient as it is
2. Assign owners (either teams or individuals) for areas that require special expertise. For example, specific technological expertise like WPF, NHibernate, etc, or proprietary, complex domain specific knowledge. However, by “Owner” I mean someone who’s involved and keeps an eye on every change made to his area – but not someone who makes himself a “job security” by preventing others from knowing what’s going on in his code
3. Do TDD (Test-Driven Development). When done right, this improves the code quality. In particular it makes the code more maintainable and therefore makes the code more flexible and cheaper to change. One of the main benefits of TDD is it makes the code inherently loosely-coupled, and therefore it’s not bound to be affected by Conway’s law
4. Do ATDD (Acceptance Test Driven Development. AKA “Specification by Example”). This helps to “glue” together all the components to a consistent application and ensures that all the functionality is always working. It also focused the developers on implementing the right thing that the customer needs, and promotes domain knowledge sharing
5. Encourage pair-programming. This will prevent silos of knowledge and make sure that the code area “owners” actually share their knowledge and not keep it all to themselves. In addition, it will improve the overall programming skills and especially the TDD skills of everyone