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.
Comments
Anonymous
February 19, 2008
PingBack from http://www.biosensorab.org/2008/02/20/inversion-of-control-part-two/Anonymous
February 20, 2008
"IoC is complex and to use it well requires training. " Can you provide some supporting evidence (anecdotes are fine) for this statement? Is this tool-complexity ("I can't figure out how to configure this thing!", concept-complexity ("I can't figure out what this thing does!") or imparted application-complexity ("My app is a mess now that I'm using this thing!")? I'd certainly agree that writing new-apps-from-scratch with pervasive DI is revolutionary, but application complexity should be reduced, and it should be reduced a lot. In my experience, the difficulty to maintain an app is correlated more closely to the application's complexity rather than the tools used.Anonymous
February 20, 2008
The comment has been removedAnonymous
February 21, 2008
I wonder if there are any other industries that do this--ignore innovation and future cost savings due to the short-term overhead of training. I do like what Ed Deming once said.. "It is not necessary to change. Survival is not mandatory"Anonymous
February 21, 2008
The comment has been removedAnonymous
February 29, 2008
I get asked a lot what tools I use, and have planned to write a post. As my buddy Harry got there firstAnonymous
February 29, 2008
Hey Nick, In your previous post you query Udi for "numbers that show that software written using an IoC container is measurably easier for a team to maintain?" I doubt he can provide them but he may surprise me. Conversely you do not share any numbers or empirical evidence to support the contrary so this dissolves into a "my experience shows" discussion. Which is fine, it just means we can both be right : ) Your example that we should not introduce revolutionary changes because 5-20 years from now the poor schlep who has to fix a bug fill find IoC “outside what they are used to dealing with.” This argument comes up often and generally involves Mort who we dismiss as an imbecile that cannot write code unless there is a visual designer to help him. Dependency Injection is an extremely simple concept. And a good IoC container abstracts the complicated parts of configuration and management to provide low friction to allow you to fully take advantage of DI. If a support dev finds a bug in the container, then yes she needs to have knowledge of IoC. Otherwise there is nothing preventing her from “Quick, write a new class, put in direct calls. Ignore the config file. Compile and go. Fix is in.” I use IoC very effectively and its usage in my applications is nearly transparent. If you are burdened with configuration, management, or training issues then you may be using the wrong container. Nothing is right for everything and IoC is no exception. But I have yet to see a valid argument against Dependency Injection. You are absolutely correct, it is a people problem. Don’t add to the problem by not investing in your people or designing and coding to the dumbest common denominator. -BillAnonymous
February 29, 2008
The comment has been removedAnonymous
March 06, 2008
As Grigori Melnik noted on my blog previously as well as his own , there was a brand new drop of the