Inversion of control, part two

BioSensorAB » Inversion of control, part two

BioSensorAB » Inversion of control, part two — Wed, 20 Feb 2008 12:46:19 GMT

PingBack from http://www.biosensorab.org/2008/02/20/inversion-of-control-part-two/

re: Inversion of control, part two

Nick — Wed, 20 Feb 2008 20:01:59 GMT

"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.

re: Inversion of control, part two

NickMalik — Wed, 20 Feb 2008 21:16:38 GMT

Hi Nick,

Love your URL. I'm a DDR fan.

We are actually already on the same page. "Writing new apps from scratch with pervasive DI is revolutionary." What makes it revolutionary?

The structure of the code changes, for the better. Your classes are cleaner and better defined, because there are constraints on the way you wire things together. What happens is that you change the way you think about code, and the way you approach development.

Support developers write code. If IoC is to have the impact it was designed to have, then Support developers need to write code in the same modern way. They have to think about the app using the same new approach.

Support developers are developers too. In many teams, there are no support developers... just developers, and they do both. That's the second case I mentioned above. Best case for adopting new ways of doing things. However, in a lot of very large organizations, and plenty of smaller ones, there are people who do nothing but support.

These folks will spend 80% of their time fixing code that was written 5-20 years ago. There were no lightweight containers five years ago. So the code they deal with (40 weeks out of the year) is not based on IoC. They are lucky if patterns show up!

Imagine you are one of these folks. You get a nice shiny new application written with IoC. You have one day to fix something. You have never seen a lightweight container before. You may, or may not, have access to a diagram that tells you how the classes relate. You have no time to read spec documents. Just fix it.

So you look through the code and try to find the places where class A method X is called. Guess what. It's not called. Not in the code, anyway. And you know it has to be called, because that is the class where the bug is. But you want to make sure that your change won't damage anything.

Quick, write a new class, put in direct calls. Ignore the config file. Compile and go. Fix is in.

And thus begins the inevitable decay.

For someone in this predicament, IoC raises complexity because it is outside what they are used to dealing with. They have to learn to think the same way as the new-code-developer. They have to discover those lessons. Learn debugging techniques. Understand what it means to drive connections through configuration.

It's a people problem.

People problems can be solved. If you create a consistent standard across the IT group, or a sizable portion of the IT group: ALL CODE SHALL BE WRITTEN IN THIS WAY, and train everyone, then you can afford to dedicate some support folks to handling ONLY NEW CODE. Put IoC and new design practices in this bucket and support it.

Then you can afford to train people to maintain the code. Because then they can "see" and "understand" the new way of thinking that comes with IoC. Their efforts to support won't introduce corruption in the design.

Revolution requires indoctrination, my friend.

re: Inversion of control, part two

Evan — Thu, 21 Feb 2008 20:09:50 GMT

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"

re: Inversion of control, part two

NickMalik — Fri, 22 Feb 2008 01:12:30 GMT

Hi Evan,

All the time. Most industries take innovation carefully.

Toyota had a huge internal fight when they decided to create a hybrid Prius, because of the huge costs of change that had to happen throughout the company and dealership network. That's the primary reason that they released the Prius in japan years before releasing in the US, and why their first two years, they produced the Prius at half-capacity and limited the dealerships that could sell it.

I should know... I bought one.

Why do you think the american car companies have such a hard time releasing new technologies?

So, to answer your question: yes, yes, yes, yes, yes.

Ours is one of the ONLY professions that puts innovation above other attributes. We are the weird ones.

--- Nick

Sam Gentile's Inessential List of Tools

External — Fri, 29 Feb 2008 21:43:59 GMT

I get asked a lot what tools I use, and have planned to write a post. As my buddy Harry got there first

re: Inversion of control, part two

Bill Pierce — Sat, 01 Mar 2008 01:01:16 GMT

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.

-Bill

re: Inversion of control, part two

NickMalik — Sat, 01 Mar 2008 02:33:17 GMT

Hi Bill,

The fact that more than 75% of the problem I care about cannot be solved with coding practice, then I have the weight of benefit on my side. In other words, there is no reason to believe, empirically or not, that IoC will actually make code easier to maintain.

That said, I like DI. It just isn't a silver bullet.

IoC Container, Unity and Breaking Changes Galore

Matthew Podwysocki's Blog — Fri, 07 Mar 2008 10:21:38 GMT

As Grigori Melnik noted on my blog previously as well as his own , there was a brand new drop of the