It’s raining IoC containers

I’m actually astonished at the number of open-source IoC containers available for use in the .NET world. There are at least 10. Man, it looks like open-source community is running out of ideas. I think it would have been more appropriate to focus on the actual USE of these containers and come up with concrete patterns and practices instead of trying to create yet another IoC framework. One thing for sure, IoC principles are being applied everywhere, and most practices are very questionable. I think there is some misunderstanding floating in the air. Your IoC framework applies as an architectural pattern, not a design pattern. It’s a way to stitch up components of your application at the application layer. It isn’t a way to resolve dependencies within your components, making your architecture stack a pain to figure out, debug and maintain. Either way, let me walk through some of the ways i have seen an IoC container used and how this applies to what i just said above.

Using containers directly

I see this nearly everywhere. People just sprinkle their container factory singleton all over the code base. Every class starts resolving dependencies internally and no one really knows what the heck is going on when they look at the code. While your classes may be decoupled, they are now coupled to a tool which they shouldn’t know anything about to begin with. Just keep in mind that your IoC framework is an add-on on top of a good object-oriented model. It should complement it, not replace it. Make dependencies obvious. Don’t hide them and resolve them internally.

Using ServiceLocator directly

ServiceLocator or any other IoC abstraction doesn’t replace the fact that you’re still using a tool that your components should be completely oblivious about. Other than that, this is exactly the same as the point addressed above.

Passing container to every single class

This is probably worse than the other two, mainly because it’s harder to refactor it out.

So, what is the solution? How does one access a concrete type from the container without exposing it to the entire world? This is actually a great question and it is that one thing that everyone decides to omit when they talk about IoC practices probably because it touches upon structuring your application layers which is really a whole different kind of animal.

The goal is to define higher-level components, which start the dependency hierarchy. Obviously, this is a major design task, but when this is done correctly your container is only used at the bootstrapper level of your application. ASP.NET MVC framework is a great place where dependency injection works beautifully. In a simple case, your controller starts the dependency hierarchy with repositories. Each repository continues with the dependency on the persistence mechanism and that could depend on transactional support. Therefore, if your container registers all necessary dependencies, resolving your controllers will automatically build the entire dependency graph. Moreover, MVC allows you to override default controller factory where you’d be using your IoC container to resolve controllers. See how neat this works? You only resolve one dependency (controller) in one place (controller factory) and you’ve got everything else built up for you. I haven’t tried this, but i suppose a similar approach can be used in Windows Forms project where your forms would essentially be that higher-level object.

In conclusion

The bottom line is your components should never be aware of any IoC framework. It is a cross-cutting concern and should always be treated as an optional tool on top of your model, while your model should always work without it. However, if you write tests you could probably utilize your IoC container there to see how well your design functions at the higher level while you’re putting pieces together.

The next question that comes to mind is ‘Do i really need all of this?’ IoC principles don’t really make much sense in small projects. You can do explicit constructor injection by hand and that should be enough. Bigger, extensible solutions would probably benefit more from this concept, but there are always buts. Although it sounds compelling in theory, it really obfuscates your application layer. Your concrete dependencies are harder to figure out just by looking at the code, especially if you have a lot of dependency nesting going on. I see it as a real maintenance issue. It’s also a barrier for new developers coming into the project.

I personally think that this is something that could be easily flushed out if IoC frameworks had support at the IDE level. I would love to see some kind of dependency walker in Visual Studio based on your container configuration. Maybe even some sort of intellisense support, which would reveal a concrete type when you hover over an interface? Sounds like a neat open-source solution? Until then, you’re probably bound to fiddling through verbose XML container configuration or strongly-typed code-based configuration solution. The bottom line is looking up dependencies is extra work and a lot of jumping around in your solution, which is something that your team should be aware of before jumping into something like this.

Every time a software developer calls himself an ‘engineer’, he ought to be bitch-slapped and brought back to earth. Why? Because software ‘engineering’ is anything but a discipline. It is cluster of emotions because everything in this process revolves around people. Everything from gathering requirements and estimating to building the damn thing is highly coupled with human intervention. And the worst of it is that anything you planned and researched can change at any time. There is nothing natural about this process. It is fundamentally flawed. It is ugly and it will never be engineering no matter which way you twist it.

But we have charts, cost estimates, human factors and…

In its failed attempts to be more like a true engineering discipline, software ‘engineers’ tried to squeeze a lot of bullshit into the development cycle to make the process look more structured and predictable. Obviously, every university started preaching this under the course of ‘software engineering’ where you spend most of your time learning about software marketing and management and very little about actual proper software development. Perhaps some of you remember the COCOMO II formulas for cost and effort calculations? This is nothing short of putting lipstick on a pig as all of these mathematical formulas still include human factors. So, do you know where all of this belongs? At a business school! It most certainly has nothing to do with engineering.

Let’s fast-forward a few years where we have big thinkers from Microsoft and other dominant software corporations who came up with the next best thing – Agile development methodology. Yet another attempt at systematic software development. This is where everything you want to complete is broken down into ‘sprints’ or iterations and then further down into ‘stories’ written on sticky notes which go up on a wall. And then you have multiple, fully-dedicated developers whose goal is to complete these stories. You also have a ‘scrum’ master, or a project lead, who keeps a burn-down chart of the remaining hours per sprint and writes down what went well and what didn’t during a sprint, so you can improve on it next time. So, it’s all neat and great. Where’s the kicker? Well, the more of these you do, the better you get at estimating costs and work. This boils down to the same thing i just talked about. Everything is guided by error-prone human instincts! There is nothing concrete to rely on. Nothing that will get you from A to B knowing exactly what to expect when you get to B. This isn’t software engineering, this is software prediction!

Software Industry – hiring morons is our number 1 priority

One of the main problems in the software industry is failing projects or projects which passed their original delivery date by months or years. There are numerous reasons why this happens and i will focus on one that i find to be the most valid based on my own experience. The point about ‘inappropriate staffing’ is the one i partially agree with. The article mentioned above discusses the issue of assigning the worst candidates out of your pool of developers for a specific task. My view of ‘inappropriate staffing’ has to do more with having people in your pool of developers who are better off decorating cakes, not developing software. This includes high school graduates, business and finance graduates and just about anyone else who woke up one day with the bright idea that they should quit their construction job and move on to developing complex, distributed, multi-threaded solution for high-end medical hardware after reading ‘C++ in 24 hours’. The absolute worst is that there are companies who not only hire these individuals, but also put them in managerial positions. Generally, no self-respecting developer would stay at a place like this because you usually wind up either constantly mentoring your clueless co-workers or fixing shitty code. How does this tie in with ‘engineering,’ you ask? Well, show me one electrical engineer who was pouring concrete the day before he was hired as an engineer. It’s a freaking joke, people! There are more morons working in this field than at McDonalds. What reliability and scalability are we even talking about?!

I code Facebook apps, so I’m a software engineer

Yeah and i play Pokemon. For crying out loud, a 12-year-old can do what you do! I’m actually surprised that NSPE hasn’t said anything about this. I would imagine this being incredibly insulting to any professional engineer. If you’re really in the dark about some of the ‘astonishing’ work that some of the hip software ‘engineers’ do, take a look at YCombinator. If you don’t feel like wasting your time ( and i am absolutely with you on this ) let me just tell you that most of these geniuses are developing twitter and facebook apps or yet another nonsensical web 2.0 service named either “Muhu” or “Fluffo” that does absolutely nothing because it’s still in “Beta” in 20-point font.

I can go on and on about this, but i think this is enough to get my point across. Simply put, software ‘engineering’ is pseudo-science. It isn’t engineering and will never be it because there is no room for human beings in formal, structured engineering process. There isn’t because there shouldn’t be any. Engineering doesn’t need it. You have a certain set of laws that apply to certain types of problems. This allows multiple engineers to work on different parts of a system and be in complete agreement on each others’ design decisions without much trouble all because of the systematic, derivable nature of the engineering process. Take this concept and put 2 software developers together to work on a task and see how well they understand each others’ design. Yep, my point exactly!

WPF roadmap

My biggest question is whether WPF will actually replace WinForms. The lack of definite answer from Microsoft leads me to think that this is probably what’s going to happen when the framework matures. I have read a few blogs where some folks suggest otherwise. However, I just don’t see a reason why you would consider supporting WinForms when you have something much superior and flexible to offer. Aside from that, what’s stopping Microsoft from screwing a major part of their community developing in WinForms. They’ve already done it with Web Service Enhancements and its support in Visual Studio 2008. VS 2008 itself was pretty much abandoned after the first service pack release, and according to this, we can all suck a big fat one because Microsoft sees more value in getting your benjamins for new licenses of VS 2010 than actually releasing a new service pack for potentially one of the worst Visual Studio releases. (if it isn’t the worst, it’s probably up there with the shitty ones)

Flashy design or back to WinForms?

There is no doubt that WPF is a good enhancement to software design process. It’s a powerful framework and with power comes complexity. Unfortunately, managing that complexity comes at a significant expense. You can either screw around with the XML markup that generates trendy UI or you can get Expression Blend and screw with it, which adds another layer of complexity on its own. Your other option is, of course, to hire a good UI designer who’s not only familiar with all of the tools necessary to work with the framework, but who can also do some design, animation programming and etc. I don’t know what the statistic is for software companies hiring graphics designers, but i have yet to work for one which actually did. Besides, considering how new this technology is, I can only wonder how difficult it would be to fill such a position.

Working with Expression Blend

My exposure with Blend was very limited and frustrating. I’ve had the chance to work with Expression Blend 2, which appears to be out of date since the version 3 is out already. I’m sure a lot of folks worked with Photoshop and its intuitive UI. It seemed much of Blend interface is borrowed from Photoshop, which at first was a great indicator. However, working with the application revealed that it is a new charlie foxtrot from Microsoft. I played around with a few features and tried what i thought was going to be an easy task – adding background image to a rectangle. I spent an hour attempting to do this and got absolutely nowhere. As was explained in this article, performing such a simple task is completely counter-intuitive. At this point, i had absolutely no doubt in my mind that this wasn’t going to go anywhere, and off this hunk of shit went from my machine. What a complete waste of time that was.

A good WPF showcase project?

I find it really difficult to actually get my hands on one. StockTrader is a good candidate for a sample WPF project to look at. However, most of its focus is on service-oriented software design, not so much on WPF. And it shows, as the project is just scratching the surface when it comes to WPF. Otherwise, i can’t recall any showcase projects with decent UI implementation. I wonder why Microsoft hasn’t stepped in and released a real-world WPF solution, just like they did Oxite for ASP.NET MVC. The lack of any decent material on WPF and Blend is also pretty astounding for such a hype both caused. All i was able to find was bits and pieces of information, nothing concrete like design patterns, specific design guidelines and such. It just seems like everything’s up in the air at this point.

I’m not even sure how to conclude this. I would probably still consider utilizing WPF for new solutions. You still have your standard set of controls and everything to get you started. The unfortunate thing is that you’ll probably not going to benefit much from the main features of the framework, but you’ll have to migrate at some point. Might as well do it now and hope that MS enhances their tools a little as the whole thing matures.