I’ve often wondered what it would be like to work with others through something as formal as RFCs, because honestly it sounds like it would only work if you have massive amounts of time to invest in planning. It seems really easy for one or more people to spend tons of time working the perfect proposal only for one or more people to shoot it down. It’s probably just the environments I have worked in that lead me to feel this way, I’m sure this process actual works well for some teams.
From my experience, the biggest problem with RFCs comes from the upfront planning costs quickly demanding the feature to be implemented, regardless of the understanding of how detrimental it is in the long run changing later on. There is always that case where someone goes "wait, this doesn't work unless we do X, which hurts us in the long term, so we should change things and do Y". Except now management and the client are so stuck, they demand the RFC regardless of X. Part of this can be mitigated by prototypes, but it is not a fail safe. Or worse, management tries to cut down the costs by involving only one technical person for a short time, who then completely misses a few critical points and the same problem forms.
I guess what I'm trying to say is: no planning or development method is going to magically cure mismanagement, unwillingness to listen and a tendency not to kill the darlings.
Good points indeed. I think you can even further say that people will just make mistakes regardless of the process. If engineers take too long to deliver it’s “over-engineering” or if the deliverable fails at any point the engineers “didn’t know what they were doing”— if requirements change suddenly along with deadlines it’s “mismanagement”. I’m not saying these are not real problems, it’s more that they’re inevitabilities and the processes we come up are just to mitigate them, not eliminate them entirely.
