Digital thoughts from a seasoned programmer About

I just don't buy into this generalization idea

By Matt Raffel on July 24, 2025

Someone recently posted "We have a new policy that all changes affecting X must be approved by team B"--this came about because a bug was introduced where a change was made by people less familar with X and not a part of team B.   Team B feels they could have prevented this bug had they been included.

The VP replied to this that "this is a bad policy".   And to sum up the VPs words:  anyone senior level and above should be enough of an expert in the entire product and therefore capably of approving any changes.  I do not see how that would have prevented the problem that caused "this bad policy".    Someone had to approve the original change to begin with!

Getting off the soap box a bit, specialization is a vital part of a team when its more than a few people.   I want to take a step back and make an analogy, to highlight specialization works better than generalization.  

There is a pipe leaking in my house.  Do I call a plumber or an eletrician?  I could call an electrician and technically the electrician could probably fix it.  But why do I call a plumber instead?   Because their expertise and their knowledge will ultimately provide a better solution.  

We do this in engineering too, even if the VP says its a bad policy.   When there is a bug in the system, do we give the bug to anyone available or to those who are best equipped to identify and fix the issue?  We give it to the most qualified person.  

Why?  Because its their knowledge and experience that will likely produce the better result.   So why not do this with product development?  

Comments

If you'd like to comment on this post, please reach out to me through the contact page .
The bikini bottom atoll is sinking. Reload 🗙
An error has occurred. This application may no longer respond until reloaded. Reload 🗙