Should or should not log defects in Agile

 The most important statement about bugs is: "Do not manage bugs, fix them". I would maybe add "and learn". When we discover a bug we need to remember that not only we've discovered a flaw in our software but also in the process we follow.

First thing first, let's define a bug at the beginning - it is any deviation from expected result. I made it so general for a purpose. We need to remember that bugs are not only related to the software we're developing but also for ex. to a build process, deployment process that we follow, and many others.

When it comes to the bug we have one simple question to ask: is the bug related to current stories (stories we work on in a current sprint)?

1. yes - fix it
2. no 
• solving bug won't jeopardize sprint goal - solve it within the sprint
• solving bug will jeopardize sprint goal - estimate it, add to your backlog and prioritize against other stories

Obviously I'm not talking about production issues as treating these beasts requires a different set of rules, including a simple rule: abandon anything you're doing and put 150% effort into solving the damn bug ;-).

How to deal with circular dependency

There are various types of circular dependencies:

• instantiation dependency - object A includes object B which in turn includes object A, hence in order to create object A you need to have in hand object B, but in order to create object B you need to have object A...
• operational dependency
• object A invokes methods on object B and object B invokes methods on object A
• classes from package com.abc depend on classes from package com.xyz, while classes from com.xyz depend on classes from com.abc

In case of instantiation dependency it is impossible to create neither objects A nor B. In case of operational dependency it might be hard to understand the operational flow and responsibilities of given module/package.

So how to solve it?

First of all let's assume that we need to keep the relation between two objects but we also need to solve the circular part of it. Let's use following classes as an example:

class Customer {

    List<Order> orders

}

class Order {

    Customer owner

}

There are conceptually three ways we can undertake:

Solution 1 - introduce an object that would hold the problematic dependencies

Solution 2 - Introduce an object which both problematic classes would depend on but the newly created objects would not depend on each other

Solution 3 - Merge both problematic classes so that it is one

This solution requires deep understanding of the business as it indicates that what we considered as separate concepts should/could actually be modeled as one.