Building an effective, elegant, and enduring architecture requires a strong vision and smart people who can implement it. The interaction between developers is just as important as the coding process. Kevlin Henney's two talks at the 2010 Norwegian Developer's Conference focus on developer interaction and architecture. Henney is an independent consultant and trainer. His focus is on programming languages, Object-Oriented programming, design patterns, software architecture, and the overall development process. Below you will find two video recordings of the sessions: "Strategies Against Architecture" and "Individuals & Interaction Over Processes and Tools". They should give some excellent insights into the technical and communicative patterns and anti-patterns that must take place in order to execute a great software development plan.
Good architecture requires good vision and good people, but there are times when actions and decisions taken with the best of intent begin to work against an architecture. Instead of helping a system achieve a long life, speculation about reuse, flexibility and generality can bring a system to an early grave, weighing the codebase down with accidental complexity that invites workarounds and, ultimately, a new ad hoc architectural style. Documentation intended to be helpful becomes shelfware, ignored equally by its authors and its prospective readership. Dysfunctional memes in code and tests go unchecked because the detail of code is not considered a part of the architecture. Instead of stability and responsiveness, an architecture achieves stasis and loses reflex.
This session looks at the reality of how development process and practices interact with the grander vision of architecture, the pitfalls of "architect as cop" and how to employ speculation and uncertainty to a system's advantage. -Kevlin Henney
Although it is a simple value, the idea that individuals and interactions are more significant than processes and tools is overlooked perhaps more often than it is valued. Of course, processes and tools make a difference –– sometimes a very big difference –– but what determines whether a process or tool is effective is related to the individuals and interactions. To best achieve agility you need to start with the current context and understand how people actually behave in response to their environment, their beliefs and one another.
What actually motivates and demotivates people, developers in particular? What actually makes their work easier or harder? Does making "business value" the centrepiece of what they do actually motivate the people who ultimately produce such business value? Or is it more about the individuals and interactions? -Kevlin Henney