[HN Gopher] Using anti-requirements to find system boundaries
       ___________________________________________________________________
        
       Using anti-requirements to find system boundaries
        
       Author : davidboike
       Score  : 26 points
       Date   : 2023-05-23 19:22 UTC (3 hours ago)
        
 (HTM) web link (particular.net)
 (TXT) w3m dump (particular.net)
        
       | davidboike wrote:
       | Using anti-requirements is a powerful way to increase autonomy by
       | breaking your domain into separate islands that can evolve
       | independently.
        
       | TeMPOraL wrote:
       | Uh oh. That's a new one for me. I was taught about the idea of
       | anti-requirements at some intro class at my university, but it
       | was presented differently.
       | 
       | Instead of trying to probe your stakeholders with nonsense
       | questions, anti-requirements were something you'd naturally come
       | up with, and which you would include in the initial spec/design
       | (and later keep track of). Their point wasn't about DDD or any
       | tactical-level thing - it was to channel the natural...
       | creativity of people during initial project planning into fences
       | around project scope. It allowed and encouraged responding to
       | "what about..." questions with a firm "no, we explicitly don't
       | care about this" - so that later, when your developers start
       | making vague hints about designing the shopping cart as
       | eventually-consistent distributed object, or something equally
       | "reasonable" from their POV, you could politely remind them that
       | this is way past the fence and far on the pasture of _out of
       | scope, not doing that_.
       | 
       | Of course, we had an exercise of coming up with anti-
       | requirements, which went about as well as the TFA with its
       | examples. Only now it finally clicked for me that anti-
       | requirements, in the sense I was taught, are about documenting
       | denials to most obvious hare-brained ideas - so obvious that
       | they're likely to be independently thought of by someone multiple
       | times during the project, and could lead to unnecessary waste of
       | time and resources if attempted.
        
       | oscillonoscope wrote:
       | I don't understand the benefit of anti-requirements. It seems
       | trivial to put your attributes in a matrix and identify
       | relationships between them. Randomly making up requirements
       | doesn't seem effective
        
         | BaseballPhysics wrote:
         | It's a suggestion for a tool to create that matrix. i.e., you
         | propose these "anti-requirements" as a way to surface
         | attributes that have no direct relationship.
         | 
         | Feels a bit kitschy to me, but with the right audience, or with
         | an inexperienced BA, perhaps it has merit.
        
           | oscillonoscope wrote:
           | But why not just create it directly? To use the article's
           | example, you can just directly fill in or ask questions about
           | the upper triangle of the matrix below. Adding in the anti-
           | requirements just adds the possibility of missing a
           | combination.                    Name  Desc Price Qty
           | 
           | Name
           | 
           | Desc
           | 
           | Price
           | 
           | Qty
        
       | jstanley wrote:
       | What about:
       | 
       | "The total cost is the square root of the quantity.
       | _Preposterous!_ "
       | 
       | -> therefore there is no relationship between the quantity
       | ordered and the total cost?
       | 
       | I don't see how this method proves which properties are related
       | and which aren't. You can come up with ludicrous relationships
       | between any two properties, but that doesn't mean there's no
       | relationship at all.
        
       | headtilt wrote:
       | How do you do this and remain employed? I get that the examples
       | in the article are contrived, but still, it seems annoying and
       | inefficient.
       | 
       | How to address the requirement "We must update the name of an
       | item every time the description changes."? This is clearly false;
       | so therefore, name and description do not belong in the same
       | entity. This idea seems preposterous and would result in every
       | field being in a separate entity. It seems unreasonable that an
       | entity can not have two fields which are independent of each
       | other.
       | 
       | What if your domains evolve autonomously as desired and as a
       | result develop a disagreement on quantity? The warehouse wants to
       | aggressively prune orphaned carts as to release inventory
       | reservations, but sales wants carts to be immortal so they can
       | remind customers that they still want to buy the things. Can they
       | really evolve independently just because this field is copied
       | into three entities? Haven't you introduced a new problem by
       | destroying the single source of truth and now must maintain a
       | synchronization of the values?
       | 
       | I don't grok this at all.
        
         | jstarfish wrote:
         | It reads to me like fuzz-testing the requirements.
         | 
         | The bigger problem I'd see is not remaining employed, but
         | getting stakeholders to ever take you seriously again after
         | harassing them with asinine questions.
         | 
         | As a thought exercise, it's cute, just not something you
         | subject _actual people_ to.
        
       ___________________________________________________________________
       (page generated 2023-05-23 23:01 UTC)