I believe it is too much. I can clearly see from my experience that extreme specialization leads to functional silos and limits accountability. However having only generalists doesn’t work neither. I think you need to be expert in your domain, but be able to understand and as well perform the tasks in other areas. Only this can lead to high-performing team with a “one for all, all for one” mindset.

Looks like I need to add this book to my reading list as well

Thanks… It’s always good to hear real-world experiences — both the positive and negative as we learn from either.

I definitely agree with your “It is not a one-size fits all…” as I apply these techniques there are many factors to consider: state of current process; team experience & willingness; management interest & buy-in, etc., etc.

Thanks again.

After-the-fact design reviews: drawing pictures on the white board of what was (will be) implemented, talking through a “packet walk-through” (s/w land would call it “use cases”, “sequence diagrams”, etc) and the like, are much more effective at catching the design issues and potential bugs.

Another case I could foresee this being effective is when building the first of many similar units (agent/driver/monitor/et al.) where this would set a common and mutually agreeable standard. After all are on the same page, going off and doing your thing will result in much more uniformity in implementation approach and decisions. It will require less rationalization of the code at a later review stage.