Klaus Marquardt started out the session by stating that complexity is inherent in any system we build and as such we need to deal with the issue of managing it. What was interesting with this session is that Klaus laid out a number of rules for managing complexity. How do we know that complexity exists in a system? usually they way to tell is by way of anecdotal evidence, "I wouldn't touch that it's way too hard", "we don't ever go there", and so forth. There's a saying that goes, "The art of programming is the art of organizing the complex". So what do we do to organize the complex? What constitutes good rules for managing or even reducing complexity ion our solutions?
But first let us try and define complexity. Wikipedia defindes complexity as entanglement and intricacy, or in other words spaghetti code referenced back and forth in no clear way. That was the way I understood it anyway :) Another way of looking it at is like this "Complexity is in the eye of the beholder" which basically means that if you possess a different skill set than another person you might see complexity where in fact it is not. This definition comes from cognitive psychology.
The first rule is to acknowledge that our managers don't want to know. If they do want to know they're probably not a very good manager because they're focusing on the wrong thing, i.e. not managing but developing. If you get a manager involved in your job, developing software, you can be sure that you're going to face complexities due to lacking understanding of the solution.
Second rule is that you cannot get rid of intrinsic complexity in a problem area. Getting rid of intrinsic complexity would mean that you in essence don't handle the problem at hand thus creating useless software.You basically need to deal with the core business to be successful in your project.
Third rule: Hype is an indication what unresolved complexity exists at a large scale. Just think about SOA :)
Fourth rule states that process and technology can increase complexity found in your project. Process because it can lead to a lot of bureaucracy which will impede development and might lead to unnecessary compromises in your projects. Technology is obvious and we're all better for it if we pay more attention to that particular one.
Thomas McCabe invented the metric cyclomatic complexity in order to describe complexity in a piece of software. Klaus believes that this particular metric while useful is at the wrong level for architectural needs as it main deals with the control flow of the application rather than more high level stuff. He went on to describe a number of metrics proposed by Robert Martin defines for describing high level complexity. These include relational cohesion (are the right pieces in the right place), afferent coupling (external dependencies in the module), efferent coupling (dependencies on the module itself), instability (how concrete are our claseses, more concrete classes means a higher level of instability. It's important to remember that instability is not a bad thing), abstractness (are we based on interfaces, abstract classes). What we're looking for in an application is a abstract and stable or instable and concrete. Interestingly this explained to me what NDepend is trying to do. As I now understand the thoughts at the hear of NDpend I'm thinking that I might have to give NDepend another go :)
With all that talk about metric how do these impact complexity? It turns our that metrics is a bad thing for complexity as they have a tendency of forcing an organization on only the metric and nothing else which means a lot of things will fall between the cracks as it's impossible to define all important metrics in an organization or for a project. In essence metrics define their own reality. By all means measure all you want but keep the fact to yourself to avoid the metrics start setting the order of business.
Foundlings is a words I'd never heard before but what Klaus means with this are classes found in a namespace which has little or none relation to the namespace it's in but has a lots of relations to other namespaces. The classes just kind of ended up in that particular namespace for no apparent reason. Which leads nicely to the next rule: Carelessness creates complexity.
The carelessness rule not only tied in with what Robert Martin spoke about at the keynote: Leave the code base in better shape than you found it. What is in play here is the broken window theory where a single unfixed broken window will lead to more and more and finally create slum. So fix that window and avoid a big mess. It's very interesting to see the parallels between all the talks, I'm definitely starting to see trend emerge at this point.
Team dynamics is another area that creates complexity becayse you now have to deal with communication in the team, some kind of preparation before a project really starts is usually needed, and probably the most time consuming effort is the time you have to spend on reworking an application to make new features work. This of course is also tied to a lack of automated testing.
We ran out of time at this point in the presentation so he quickly fired off the remaining rules of complexity which are:
9: Where there is taboo there is complexity. WIf we don't talk about it it probably indicated a problematic area.
10: Local optimization adds complexity. Think higher optimized assembler code sprinkled around your high level C# code.
11: If previous project was complex for a team changes are that the next one will be too. The thinking here is that a team will keep doing what they know how to do, i.e. if they've gone done a significantly complex route previously chances are that they will do so again.
12: Indecisiveness yields complexity. Factors multiply, so if you have a lot of configurability, branches, versions, interconnected products, and options you'll have to deal with a lot of combinations of those factors making for a very complex system.
13: You can rid yourself of chosen complexity. Say for example that you've chosen some kind of standard product to solve a problem, you can get rid of the product or outsource development and rid yourself of the problem. Of course this might cause other problems but you got rid of the other one :)
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.