Michael Feathers has spent his last 10 years studying large existing code bases and trying to understand what influences their structure. He is well known for his book “Working effectively with Legacy Code”, a book that describes some of the techniques a developer can use to figure out what code does and how to change it safely. Both me and Adi are big fans of his work, since we both dealt with legacy code bases and learned in the hard way how to do it.
He explored in his keynote how code is influenced by external factors. He mentioned Conway’s Law (“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”) as the fundamental law of how code evolves. He then discussed how organizing a project in component teams will create more internal APIs while organizing a project in feature teams will create a design with less components. It does not mean component teams are better or worse than feature teams, only that managers need to consider the effect on the architecture and design of the product when choosing between the two. The third factor that influences design is the organizational focus; focusing on projects creates different designs than focusing on products or users.
These factors are important because code is the long living artifact of software development. Team structure changes, people come and leave, even the organization changes, but code survives these changes (unless, of course, the project outlives its usefulness). So should not we pay more attention to the code than we currently do?
He proposed during the keynote that maybe we should rethink the “people over processes” statement from the agile manifesto and consider adding code in. Since code is the lasting artifact of software development, maybe “code over people over processes” would better explain it. It has however a problem, that reading such a statement might incorrectly imply valuing people less. I think it is just a matter of placing each of these three elements at their right place; code is important because it lives long, people are important for obvious reasons, while process is important as long as it facilitates interactions and eliminates misunderstandings. They all fit in a mosaic of practices that helps us develop better software faster.
During the conversations after the keynote, he mentioned his work in making visible the qualities of software so that a manager could understand them. It is much easier explaining to managers why a story will take a longer time than expected to implement if you can show on a diagram that hits an area of the code that looks very intricate. It is probably much easier also explaining where technical debt is and why it is necessary to reduce it. I plan to explore this topic in more detail.
I enjoyed Michael Feather’s thoughtful keynote and I plan to use some of the insights into my own activity, building a software team in Mozaic Works.
Is technical debt a problem? Try:
- Pair program with one of our coaches on refactoring existing code
- Attend the “Working FAST and Safe with Existing Code” workshop, also available in-company
- Attending the “Refactoring” workshop, also available in-company
If the situation is more complex, we would be happy to create a customized package for your needs.