The definition of Inversion of Control was presented in a paper published in 2015 (a free download is available here). The premise of the paper was “can we learn something from how businesses organise themselves and translate this into software design improvements?” Basically, businesses have been around a lot longer than software systems. So, how did businesses deal with problems, such as scale, before computers existed?
So running with this analogy, I looked at how businesses evolve. Businesses don’t set out day one to be a Fortune 500. Typically, they start with you in your garage (maybe with a friend). Overtime your business grows and you hire people, assign clearer functional responsibilities and start to scale up your business. Businesses have to do this, while also changing quickly to stay competitive.
Within software, we have moved from Waterfall to Agile. Waterfall can be considered your set out to build a Fortune 500 company day one approach. Agile, on the other hand, says build only things of value and evolve your system over time. Also, Agile focuses on being quicker to react to change. Therefore, Agile is a lot closer to how businesses grow, evolve and stay competitive.
Unfortunately, our software architectures have still stayed a “waterfall” top down approach. Architects will produce technology stack diagrams that indicate how the architectural layers of the system work (those technical pictures full of rectangles on top of each other). The nature of these
layers is always a bureaucratic control from the top layer to the bottom layer. This is very similar to large companies with many layers of management. So our software architectures force us to design the
Fortune 500 company before developers even get to write the first line of code.
Inversion of Control is like empowering employees in a business. Rather than the manager dictating exactly how the employees will work, the manager trusts the employees to undertake the goals of the business. In other words, the employees are in control of how the work gets done. They will decide what help to get (Continuation Injection). They will decide what business resources they require (Dependency Injection). They may decide to escalate issues with the work (Continuation Injection). They may even decide another employee may be better suited to do the work (Thread Injection).
By empowering the employee, we have inverted the control. The employee is now in control of how the work gets done. This is similar to the Inversion of Control in software. The developer is now in control of how they write code. They are not restricted by bureaucratic top down architecture controls from their managers. This allows the developer to evolve the business’s software quickly so it may grow and stay competitive.
Published on Java Code Geeks with permission by Daniel Sagenschneider, partner at our JCG program. See the original article here: Inversion of Control (explained non-technically) Opinions expressed by Java Code Geeks contributors are their own. |
Am I the only one who has no clue how IOC or dependency injection in general is related to management and who controls architecture layers?
‘Inversion of Control’ as a computer science term and concept predates that 2015 paper by at least 27 years.
Hi Ash. Yes, the Inversion of Control principle predates the paper. However, the paper is looking at realising Inversion of Control as a design pattern. I clarified this on the original blog: https://sagenschneider.blogspot.com/2019/03/inversion-of-control-explained-non.html