What is the business case for a dependency injection (DI) framework?

Question

At my company we want to start using a dependency injection (DI) framework for managing our dependencies. I have some difficulty with explaining the business value of such a framework. Currently I have come up with these reasons.

• Less source code, delete all the builder patterns in the code.
• Increase in flexibility. Easier to switch dependencies.
• Better separation of concern. The framework is responsible for creating instances instead of our code.

Has anybody else had to persuade management? How did you do that? What reasons did you use?

Answer 1

Although the comment above is right in pointing out that it should be the developers who make the coding and design decisions, the point is that management is the one who pays the price. Sponsors are understandably not very willing to accept code/design changes which consume project resources without any visible, tangible benefit.

Your arguments are valid, but might be a bit too technological for management. I would sum up these (and also the one about testing made easier) as making an investment for future benefits. By refactoring the code to introduce DI, you make the code simpler, easier to understand, maintain and extend. In the long term, this results in reduced maintenance costs, lower bug rates, thus increased customer satisfaction.

To support this with real data, you could try working out some method of estimating / collecting data / statistics about the results of introducing DI. Such as:

• the same functionality is now implemented with n% less code
• switching from framework A to framework B, or from database C to database D would require this much person days/weeks of effort with the current setup, while only half of it using DI
• due to the unit tests we could write thanks to introducing DI, we could catch this many bugs early, before passing into production, during the last m months

Answer 2

If done right, code becomes more reusable. Developers learn how to write components which can be wired differently for multiple situations and can then be reused. Without a DI, code reusability just doesn't happen as easy as with DI.

Testability can be increased easier, as components can be wired with Mocks very easily. The testability and maintenance of hard-wired legacy software can become a nightmare. We did that on a medium-sized SOA landscape: migrating to Spring DI Framework to enable testability for small components, piece by piece. With DI, the maintainability was much better.

Configuration becomes more obvious in a central place, stuff like number of maximum threads, database connection settings, debug switches etc. They're all simple setter methods and configured in the DI container.

What might be a business case, dependending on the type of software you're developing, is that with a DI container, you may be able to switch implementations at runtime. This is a bit exotic, but comes in handy once understood where to apply it.

Another thing is that, looking specifically at the Spring Framework, the high-quality of the framework itself and the coding style used there, people started to learn how to write better code. That alone is worth it. Monkey see, Monkey learn, Monkey do.

Using a DI framework is an architectural decision, but also goes down to the coding guidelines. New people joining your team will have it a little bit easier to understand your software. A Dependency Injection framework will get new collegues faster up-to-speed.

Answer 3

The business case would be that DI allows to better manage dependencies in code, which enables better maintainability. I do not think, business needs technical reasons.