Programming - especially in Java or .NET - often seems overly complicated to me. I know complex problems sometimes require complex solutions. I am ok with that. It can be fun to work on a complex problem, even if it yields a complex solution. It can even be fun to read and maintain such a complex solution when it is written well. But complex does not necessarily mean complicated.

I do have a problem with frameworks that require complicated programs. This is the reason why Oliver Szymanski and I created the direct call pattern. This is why we created JSXP. But that is not the topic of this blog post. I will write more about the design principles of JSXP in a later post (Update I now wrote that promised blog entry about the history of JSXP). This blog post is about “accidentally complicated” programming.

A program gets “accidentally complicated” when the programmers use tools or language features that are meant to make their lives easier in a way that makes the program very hard to read and maintain. It takes a significant amount of time to understand what is going on in the program, and refactoring or adding features becomes near impossible.

One of the language features are events and observable properites/collections in .NET. Without them, data binding in WPF would not be possible and some other programming tasks would be very hard to accomplish. The problem is that it is very tempting to sprinkle the whole code base with code like this:

object.Collection.Changed += {s, e} => { /* do something */ }

This already has the potential of becoming a maintenance nightmare, but when “do something” means “change a property that raises change events itself” it really gets bad. I have been working on code like this for a customer - It is no fun at all!

The same thing can happen in Java projects with spring: When more dependencies are managed with spring and configurd externally it becomes harder to understand what is really going on at runtime. Add aspect oriented programming to the mix and it gets messy again. (A spring project at one of Oliver’s customers was one of the reasons we wrote the direct call pattern)

What I wrote so far does not mean that events, dependency injection, AOP and other tools are dangerous. These tools are very useful for solving certain problems, but they can cause programs to become overly complex. Using tools like this and keeping a software system simple is hard and requires effort. Maybe I will write more about keeping systems simple in later posts.

I already mentioned one of the problems these tools cause: It becomes very hard to understand what is going on at runtime when all you have is the source code. But the problem goes deeper than that. The benefits of these abstractions are local and grow linear: Using more events for communication means more local code that is easier to write. The drawbacks, on the other hand, are global and grow non-linear: Using events (in the way I described above) makes the whole system harder to understand.

Why is it still a good idea to use these tools, language features or abstractions? The chart above is one attempt to show why. There is a point where the drawbacks of using the abstraction grow faster than the benefits, but up to this point it is a good idea to use the tool/feature/abstraction. The hard thing is to find this point - or at least to make sure to stay somewhere below it.

An even better way to avoid this accidental complexity is to limit the drawbacks. This means to only use the tool/feature in well defined places and to limit the interactions with the tool/feature. In the case of the .NET events this can mean to only use observable properties/collections for binding data to the view, not for all kinds of data flow in the application.

Both strategies require that the team has a shared understanding of the architecture and the design of the system and of the possible traps along the way. I guess regular, short meetings and a big whiteboard are a good start to achieve that ;)

You might be also interested in… Learn more about how I can help you save money and earn money by simplifying your architecture and code.