We've all had them... that person on the project who just seems to always be asking for help on things that they don't really need help on... Let's call them “Pat” - a genderless name. 

So Pat's obstructionist today was 'Lets tie up as many people as possible on a technical question which doesn't actually concern me.'  Pat is working on a portion of the project that acts as a parent to a set of child records.  As part of the default behavior when the default value provided in the parent record varies from one or more of the child records this value fact is indicated visually onscreen so that users know not to change that value.

Similarly one of the properties of this object is a collection.  This collection of objects is of course represented by a different table, and once again each child might have a the same or a different collection of these objects. 

Now from a technical standpoint there is no reason the software couldn't carry out the same dynamic check for similarities.  However, for performance reasons checking to see if the contents of a collection match across 1000 different entries takes the logic from a simple to performance intensive.  So as a result in the portion of this logic is being designed to indicate if it was customized and the rules are less dynamic since once modified the flag won't be reset...  easy enough so far.

Along comes Pat, who is working on the parent, but has been explicitly excluded from looking at how to design the collection or how the collection will work. 

First Pat contacts the application analyst and asks “How will this indicator work and will it be in the database?“  The application analyst contacts the technical lead, who describes the design. 

Next Pat is off to the part-time DBA, “How will this indicator work in the database and how come we decided not to store it in the database?”.  The DBA contacts the technical lead, who describes the design.

Finally Pat contacts the technical lead, “I've spoken to everyone else and they all say we aren't keeping an indicator in the parent object for when these fields vary from the child values.  But that's not what I read in the design for the collection.”  The technical lead explains the design once again, at which point Pat declares “Well I guess since I'm not working on the collection portion of this object that portion of the design doesn't really impact me.”

This folks is your obstructionist.

Pat has managed to not only ask three different resources the same question, and interupt the technical lead at least 3 times over the course of the day, Pat has done so with a question that Pat knows doesn't apply to what Pat is working on.

Beware you may have a Pat in your organization, or on your project.  If you are lucky you will be in a position to terminate Pat, because Pat isn't just worthless to your project - Pat causes your project to fail.