It’s very easy to believe that our code does a lot of different things – we live in a world of incredible complexity with well over 10,000 classes and 100,000 members in the .NET framework (1). We write code of great complexity – sometimes it’s amazing that it even works.
Take a minute to stand back from your code and consider what it actually does. I have the privilege of being part of the Northern Colorado Architects and we asked ourselves this question last spring. I’ve mentioned that we found about a dozen in several talks, and was asked to share the list. I’d like you to challenge this list if you think your code does anything else. Well, that and because I think I am forgetting at least one:
- Exception avoidance and recovery
- Workflow (*)
The complexity of our world comes from the thousands of ways we can do each of these things and the billions of combinations. The complexity of a particular software application comes from tossing all of these concerns together along with a top- dressing of entropy and stirring vigorously.
The first three items on the list are pretty straight-forward. There is similarity between validation and authorization because they are both guards, but one focuses on who and the other on what, and we tend to use different techniques.
Localization may eventually fold into Display/Edit but today code on that front is rather different. Display/edit and reporting are also very similar. They differ because reporting is complex read-only analysis which might not be done over current data and may or may not ever appear on paper.
Three of the items on that list we do for internal purposes: logging/ auditing, testing, and exception management. Assertions and code contracts are part of exception management and what I mean by exception avoidance. Something is wrong and we’re responding to that, rather than crashing our systems – but it’s still a response to something being wrong. Logging and auditing covers all system health reporting and hopefully testing is a straightforward concept – even if it’s not straightforward in practice.
You might consider it cheating to have two buckets as big as “process” and “calculate.” Certainly they are critical and complex. But from a concerns point of view, it doesn’t really matter what you are doing – you’re doing it. I make a distinction between a process that changes the state of the universe (often by altering a database or an external system) and calculation which supplies information without altering the state of the universe.
Only three things (other than workflow) on this list should alter the state of the universe – persistence, logging, and process.
Workflow falls into a very special category. I mean a specific kind of workflow – the interaction between the application and the non-software business world it lives in. I don’t mean using workflow or business integration tools to do processing. I’m not actually sure workflow should be on the list, because in practice, it merely uses the other eleven kinds of code. At the end of my contemplation, I include it because I’d rather not spend time arguing about whether it should be there. I do believe that this sense of workflow is one of the most important perspectives we can have when we step back from our code and think as analysts. It’s a perspective that includes user stories as a subset.
There’s a lot of grey area where the things our code does overlaps. Is there any code in your space that does not fall into one of these buckets?
It’s a profound view. Everything is a cross cutting concern.
(1) Brad Abrams, Number of Types in the .NET Framework, http://blogs.msdn.com/b/brada/archive/2008/03/17/number-of-types-in-the-net-framework.aspx