This is the fourth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Not even remotely comprehensible
A lot of software is built today by adding feature after feature very quickly without considering understandability and maintainability.
The result is that new features find their way into the software slower and slower because understandability drops over time.
One of the main reasons for this is that a developer needs to know much to much to simply change a single line of code without breaking anything else in the system.
Everything is linked together. The developer needs to keep the whole system in mind, which gets impossible after some time in the project.
The only way not to overburden our minds is to cut the system into parts that are mostly independent.
And then build the system from these building blocks. Whenever I work inside such a building block, I can ignore its environment as long as I don’t change the interface and its contract (externally visible behaviour is unchanged). And when combining building blocks together, I only need to know the contracts and interfaces and can ignore the implementation details. Therefore, my mind is not overburden any more and I can work quickly and without errors (almost anyway, and don’t forget to write tests or executable specifications for the modules!).
Finding building blocks
We gather requirements as themes and epics. Then we split these epics into user stories that can be implemented in a single Scrum Sprint.
Technically, a user story is implemented by a set of building blocks (we named them feature). To process an order, we could for example have the features load data, process and notify customer. These features have a well defined interface and contract. Therefore, we can use them in any environment, just by glueing them together in different ways (which is really great for product families).
Now, our system is built from building blocks (features). Whenever we add or change something in our system, you have to comprehend only the feature you are changing. This really helps to stay sane 😉
We use Ninject.Features to glue our building blocks together.