Inversion of control, part two

I started an interesting thread when I weighed in on the use of IoC and the Dependency Injection pattern a few days back.  Seems I wasn't sufficiently supportive of the concept of lightweight containers to please some of my readers. 

Should we, the blog community, encourage IT developers to adopt new coding practices? 

Hmmmm.  Well, if in doing so, we are doing their organizations a favor, I'd say yes.  Increasing their understanding of the tools and the limitations of the environment certainly qualifies.  Encouraging the adoption of standards is generally 'good' as long as you don't add costs.  Encouraging the use of a lightweight container may, or may not qualify.

You see, the maintainability of an application depends not on the application, or where the requirements come from, but rather the organization that must maintain it.  Who are the people, and what do they do?  How close or friendly is the relationship between development and support?  How are fixes funded?

Understanding the organization, the processes, and the people who will benefit from any new coding technique is the first step to understanding if there is a benefit to using it. 

So, while my prior post focused on the tradeoffs of IoC in business software, this one focuses on the tradeoffs in development tools and process that impact an organization.

In general, I'd classify tools and techniques into two buckets: evolutionary and revolutionary.  I'd say, in general, the use of complex OO design patterns was revolutionary.  It requires training to understand how to leverage the use of a bridge pattern when maintaining systems.  Other things, like moving up a version in Visual Studio tools, is more evolutionary.  IoC is complex and to use it well requires training.  I'd consider it revolutionary.  Quite trainable, but still revolutionary.

Organizations should strive to find a solid balance between practical efforts to develop good systems, and the availability of talent that can maintain them.  If your support team is not the same group of folks that writes the software in the first place, and if they have a higher turnover rate, requiring you to replenish staff from the general programming community, then it is in your best interests to optimize the 'ramp-up' period for a new support developer.  One way to do this is to limit the number of revolutionary shifts between "average developer from the street" and "functional developer in an organization."  Depending on your choices, that may, or may not, include the use of complex pattern-based systems like an IoC container. 

Why do you think RoR is so popular?  Because it hides so much of the complexity, yet surfaces a great deal of power.  Same thing goes for LINQ (in a different way, of course).  When complexity is low, the change is more evolutionary, even if the shift in capabilities is dramatic.

Contrast the above situation with a different one.  If your support team is a rotating set of folks who both develop new systems and support existing ones, and your body of code in support is not very large, then it makes perfect sense to experiment with many revolutionary changes in coding techniques.  After all, you can train once, and leverage the training across a body of code. 

The point is that the successful use of any revolutionary technology depends on the organization's ability to swallow it.  If your organization is structured to foster the introduction of new techniques and ideas, then by all means, adopt the appropriate ones, including lightweight containers if that appeals to you.  You can train folks on design patterns in general, and DIP in specific, and you can refactor existing systems to use these patterns.  Hopefully, you will have designed your system interfaces correctly so that you can get the benefit of the easy configurability promised by the IoC coding technique. 

Many of the quality attributes are dependent on people.  Maintainability and supportability among them.  So if you honestly evaluate the use of a technique or tool in a particular system, you will need to consider the organization that will own the result.  If they are not ready, it doesn't matter how good the technology is... it will not be useful.

Software reflects the structure of the organization that builds it. 

That axiom is as true today as it was when it was coined.