The Complexity Suppression Disorder
time to read 2 min | 325 words

So, applying the separation of concerns principal to blog posts again, I wanted to talk about another aspect that had me thinking as a result of teaching .Net. I literally had no idea how complex development was until I had to stand in class and explain the tradeoffs for the various approaches for implementing things. Several things that kept popping up are:

  • Concurrency
  • Multi thread safety (in the abstract, at least) - That one is easy, don't do multi threading. Failing that, don't do multi threading on shared state. Failing that, welcome to the fun world of multi threaded debugging :-)
  • Normalization
  • Ease of use (API wise)
  • Information hiding
  • Exception non-handling *(not a typo)

Those are cross cutting concerns that affect a lot of the actions in the application. When I develop, I don't think that I am really aware for this, I just write code according to the best practices that I pub-sub to, and it usually end up being correct.

Having to implement a solution in front of a class, it is much more difficult, because now I have to articulate these best practices, why they are important and their reasoning. This made me realize how often I do the same without really bothering to go through the entire check list.  Did you know that Rhino Mocks has a mode that is actually safe for multi threading, for instance?

Now I need to re-learn how to forget about all those messy concerns and just build the application the way it is supposed to be, without starting to worry about all of those concerns until I really need to.

Nevertheless, it is pretty amazing that I can spend 30 minutes talking about 15 lines of code, pointing out all the various concerns that it needs to handle, and how it does them. It is amzing and depressing in the same time, we need to handle so much stuff that this is getting ridiculous.

Tweet Share Share 0 comments
Tags: