Yet what is the journey of the software developer in many large product groups? After graduating from university, a young developer joins a large company and is assigned to a new or existing component. She writes the original code or evolves it, becoming the specialist. There she stays for years—apparently so that the organization can “go faster” by exploiting her one specialty—becoming a single point of success or failure, a bottleneck, and learning only a few new things. The university did not teach her good design, so where did she learn good from bad? How can she see lots of different code? How can she see opportunities for reusable code? How can she help elsewhere when there’s a need?
I have seen a lot of this. This was one of the main reasons I wanted to try an agile method at my job. I hate getting stuck being the expert on one thing. After a while I feel like you stop learning.
Perhaps the greatest irony of component teams is this: A mistaken belief behind their creation is that they yield components with good code/design. Yet, over the years we have looked closely at the code across many large products, in many companies, and it is easy to see that the opposite is true—the code in a component maintained by a single-component team is often quite poor.10 For example, we will sit to start pair programming with a component team member (who knows we’ll be looking for great code), and with a slightly apologetically grin the programmer will say, “Yeah, we know it’s messy, but we understand it.” What is going on?
I am guilty of this. There are definitely parts of my code that I would have to apologize to the person that has to come behind me. A lot of things we have identified solutions for but haven't made the time to fix them.
Product groups that repeatedly rely on single-skill specialists are limiting learning, reducing degrees of freedom, increasing bottlenecks, and creating single points of success—and failure. That does not improve long-term system throughput of highest market-valued features or the ability to change quickly.
Whenever I hear someone say we can't move this person because of this engine or that engine, I wish I could respond with quote as elegant as this one. The book makes some good arguments for what it calls feature teams. Teams that are comprised of individuals with varying skill sets that can take a feature and complete it from beginning to end. The teams stay together for years at a time so they can jell. The team works on one feature at a time to avoid the overhead of multitasking. The features the teams work on do not necessarily have to be for the same component instead they should work on the features that add the highest value for the customer.
Why is it hard to learn new areas of the code base? Usually, the symptom is incredibly messy code and bad design—a lack of good abstraction, encapsulation, constant refactoring, automated unit tests, and so forth. That should be a warning sign to increase refactoring, unit tests, and learning, not to avoid new people touching fragile code—to strengthen rather than to live with a weakness.
The common argument for component teams is that it is too hard for developers to learn new code. Here is a good reason why this is so hard. I like the idea of confronting the issue and solving the real problem instead of hiding the symptom.
Successfully moving from solo to shared code ownership supported by agile practices doesn’t happen overnight. The practice of component guardians can help. Super-fragile components (for which there is concern16) have a component guardian whose role is to teach others about the component ensures that the changes in it are skillful, and help remove the fragility. She is not the owner of the component; changes are made by feature team members. A novice person (or team) to the component asks the component guardian to teach him and help make changes, probably in design workshops and through pair programming. The guardian can also code-review all changes using a ‘diff’ tool that automatically sends her e-mail of changes. This role is somewhat similar to the committer role in open source development.17 It is another example of the lean practices of regular mentoring from seniors and of increasing learning.
This is an awesome idea on how to transition from the knowledge silos to collective code ownership. I think this could really help my company. He gives a bunch of other cool ideas as well including an architecture code police who continually reads the code looking for problems to bring up. Another idea is a lead architect who is initiator of a community of practice that keeps all the other architects talking. There is a similar role and community for other positions including testers, product managers, and coaches. Joint design workshops are used to tackle tough architectural problems.
This was an awesome chapter. It really gave a lot of good solutions. The beginning of the book was hard to read because of all the theory. I think it is worth it but I am scared people will give up before they get to this part of the book.
No comments:
Post a Comment