Knowledge Envy – A Sign of Poor Organisational Design

In modular software design, one key aim is to encapsulate processing so as to minimise the need for modules to talk to each other. This helps to localise the “blast radius” of impact when we make changes. The mantra “put the work where the data is” – or if you’re more outcome-oriented like me, “put the data where the work is” – is a useful design heuristic that helps us to package concerns more cohesively and hide details of how work gets done behind much simpler interfaces. A common modular design smell to look out for – at every level of modular design – is Feature Envy. When, say, a method of a class or a web service needs to access multiple features of a dependency it uses to do its job, that’s a sign the responsibility is in the wrong module. By moving the logic to the object (perhaps literally) of the envy, we can encapsulate the details and reduce coupling between the modules. I’ll be blogging a lot of modular design in the run up to Christmas – for all the architects who…

Commenting on Bubbles has been removed. Why? If you want to talk about this post, write to the author, use the comments on their blog if it has them, or reply with a "RE:" post on your own blog. Suggestions? feedback@bubbles.town