There have been a number tweets recently regarding Tom Nichol’s article on The death of expertise
It’s always very difficult to summarise an article without losing context, so I recommend reading the full article, but I think the essence of the article is in this quote:
In any discussion, you have a positive obligation to learn at least enough to make the conversation possible. The University of Google doesn’t count. Remember: having a strong opinion about something isn’t the same as knowing something.
I think this a point worth talking about with regards to Agile development, especially Scrum and XP teams. Before my company worked using Scrum, all of our development was done using the waterfall and the PRINCE2 model.
Business Analysis was always done by a business analyst. We had several technical leads who were responsible for writing technical design document for any piece of work. This design also needed to be signed off by a solutions architect before a line of code could be written. For any complex database changes, a database administrator would be involved.
Developers tended to be experts in one or two systems, and the technical design document was usually detailed enough to make the development work pretty easy to do. Once the implementation was complete, it would be shipped over to a QA test team. Once this was finished, if a given code freeze period had elapsed it could be released to live, otherwise the release would be rescheduled until after the end of the code freeze.
Moving to Agile changed all of that. QA/Testers were moved into the development team and encouraged to get involved in development work as well. All member of the development became much more responsible for the business analysis. Technical leads roles were changed back to senior developers. Shortly before one of our best guys left he said “I was a senior developer, then I got promoted to Technical Lead and now I am a senior developer again. How is that going to look on my C.V.?”. The test manager role disappeared. The Solutions Architect, Business Analyst, and DBA roles changed substantially. A lot of people were left feeling unhappy.
There were no longer any experts. Instead everyone had equal say in the what the process should be and what the solutions should be. You could say that everyone was an “expert”.
Surely a recipe for chaos? Well, actually no. We found that in many cases developers knew a fair bit about architecture and design already and had some ideas worth sharing.
Testers were able to learn SQL quite easily and this helped them to better understand the system and test more effectively. However going further and allowing testers to do all development was agreed to be a step too far.
Making developers more responsible for testing forced them to think about the solution more form the customers point of view. Developers were suddenly in a situation where the need for cross-training became very obvious. They also found that the key information on a new system could usually be distilled down and learned in just a few hours, or a few days.
One result of the change to Agile was a much higher turnaround for delivery of work. But with regards to whether the code quality is higher or lower? I think it depends on how you measure quality. Quality is not something that you can fetch of bucket of. You can only measure it by proxy. I think if the measure of quality is customer satisfaction, then Scrum has resulted in higher quality. Customer satisfaction is the highest priority for an Agile team.
I think that the area where the death of the expert role is of most concern is the DBA. Poorly designed db schemas cannot be easily refactored like objected oriented code. Sometimes spaghetti object oriented oriented code is tough to refactor into shape, but a database created without the necessary foreign keys and other integrity checks is often beyond repair. Also with the rise of NoSQL products and the increasing complexity of RDBMS, there is more than ever to learn to be proficient in high performing database solutions. Agile teams are responsible for ensuring that they keep up to date with all of this and continually review each others work to keep the quality high.
What do you think?