My predisposition to patterns is one reason I enjoyed Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Susan Robertson.

If you don’t recognize those names, it’s the Atlantic Systems Guild, the same group of people that wrote Peopleware. In Adrenaline Junkies and Template Zombies, the guild outlines common project and organizational patterns that they’ve observed throughout their careers. Many of the patterns tend to be anti-patterns, rather than traditional patterns you would want to emulate. This is also why so much of the book struck me as humorous, if only because they may be familiar from your own experience.

My favorite pattern in the book happens to be the first one, which is Adrenaline Junkies. From the book:

You probably recognize the characteristics of the adrenaline junkie organization: Priorities are constantly shifting; everything is needed “yesterday;” there’s never enough project time before delivery; every project is urgent; and the urgent projects just keep coming. Everybody is frantically busy . . . all the time.

People in these organizations do not think strategically. Work gets done on the basis of its urgency alone. Unless a project’s “frantic factor” is high, it will be ignored – even though it promises a significant long-term advantage. It will remain ignored until it suddenly (surprise, surprise) becomes urgent. Adrenaline junkies believe that the best way to work is not by planning but by running as fast as possible.

Most of us have probably seen individuals, teams or entire organizations exhibiting this behavior. It’s all too often to find an adrenaline junkie developer, as they tend to be the types who see their entire job as the act of writing code. If they aren’t writing code, they’re wasting time, since planning, design and research are more strategic actions and not directly related to that urgent bit of deliverable they’ve just been asked for. The pattern even highlights the fact that adrenaline junkie organizations tend to “enthusiastically embrace the customer service ethic: They confuse responding to urgency with admirable responsiveness.” The truth, of course, is that treating all requests equally based only on urgency, without thinking about the larger value (or even usefulness), is actually a disservice to your customer.

The book’s goal is to capture and identify common patterns, and there are dozens of other patterns which are equally interesting. It only glosses over what can be done to fix projects or teams that exhibit anti-patterns, but understanding the behavior is the first step to addressing it in any event. It’s a good read that is likely to give you a better understanding for behavior you may encounter during your career, while also entertaining you. If you’re at all interested in the soft skill side of IT project work, I recommend checking it out.

Now I’m adding ASP.NET MVC in Action, by Jeff Palermo, Ben Scheirman and Jimmy Bogard to my recommended reading list for serious MVC developers.

ASP.NET MVC in Action

If you’re already familiar with unit testing or tools like dependency injection, it’s probably safe to skip Sanderson’s tome and just dive into Palermo’s. The book does a good job of quickly covering the basics of MVC, then moves on to more advanced topics, such as customization points within the framework, refactoring components that are likely to get bloated, best practices (including use of MvcContrib), some recipes and even a chapter on MonoRail and Ruby on Rails. Throughout all of these sections, the pace is brisk, covering a lot of ground without an obvious intent to bulk up the page count. I love it when authors respect my time and intelligence more than the publisher’s wish to ship a thousand page boat anchor.

What I like best about the book is that it’s not built from the perspective of Redmond isolationism and actually acknowledges other communities, tools and approaches, while still staying targeted at the ASP.NET MVC developer crowd. There should be more books like this.

All that said, it’s more advanced than the other books, so if you never played around with the MVP pattern in Web Forms, haven’t ever written a unit test and don’t know what DI stands for, you’ll still want to start with the NerdDinner sample (skip the rest), then read Sanderson’s book before jumping into In Action.

A code fossil of my own is the caching system I built using .NET 1.1 in the summer of 2004. What follows is a short synopsis and critique about the code.

Requirements

The application I was building was a rather simple content-aggregation web application. One of the business requirements was for it to “be fast” which typically translates to “is cached”. At a high level, here are some requirements:

• Content retrieved from other systems must not access those systems for every request served (i.e. content must be cached locally to minimize load on source systems).
• Should source systems be unavailable at the time of cache expiration, cached content should be retained and used.

From these basic requirements, I seem to have added my own:

• Cache configuration should be flexible, so that it’s possible to disable caching globally or change where any given piece of content is cached using a configuration file.
• Cache settings, such as expiry method and duration, should also be configurable without code changes.

Implementation

From these requirements (including those that I made up myself) I built the ContentManager class and it’s partners in crime, the CacheManger and IDataLoader:

Essentially, these classes (along with a few others) worked together so that the application code would request a piece of content using the GetContent() method on the ContentManager singleton (ContentManager.Manager). The ContentManager then determined if said content was cached and invoked the LoadContent() method on CacheManager’s singleton, which either retrieved the content from cache or triggered the ContentNotFound event. The ContentNotFoundEvent then, through a strange design decision, invoked the ContentManager to load the content using an IDataLoader that was resolved using some XML configuration in custom sections of the Web.config file for the application.

All of this resolution was done with three layers of configuration: content mappings, cache categories and content loaders. Content mappings linked pieces of content to a cache category, which specified where and how content was cached (for instance ASP.NET Application, Session or Cache objects). Content loaders mapped content to classes that loaded the content when it wasn’t available in the cache. As outlined above, all of this was done using custom configuration sections in the Web.config, meaning that it involved several more classes to map all this information within the application.

Critique

This design makes me squirm, to the point that I was hesitant about posting it at all. First of all, when it’s all said and done there are ten classes dedicated to all this mapping, configuration and dynamic caching. To cap it all off, the method signature for GetContent (and related) looks like this:

public object GetContent(string contentKey)
{
    object content = null;

    // Redacted to protect the innocent

    return content;
}

That’s right, the entire system hinges on (case-sensitive) magic strings and returns object.

In the end, here are some things that immediately pop to mind when I look at this code today:

• YAGNI & KISS: The truth is, a lot of this caching code was just fun for me to play with. I was brand new to ASP.NET at the time, so I got to learn about custom configuration sections and all the various options you can set when putting items in System.Web.Caching.Cache. In the end, though, these settings never got tweaked once the application development was done and there were better things I could have spent my time on. It’s true that being able to disable caching was useful during the development cycle, but I wasted a lot of time building an overly flexible cache system that simply wasn’t needed.
• Avoid anti-patterns and use design patterns sensibly: Heavy reliance on the magic string anti-pattern for all the cache mapping resulted in a brittle system that tightly coupled URL patterns to the underlying content. Additionally, while singletons are useful in some situations, applying them here makes it difficult to unit test any code that uses these classes (which, in this case, is the rest of the application). Not surprisingly, this application has very few unit tests.
• Use Output Caching: The saddest part of this entire endeavor is that all that’s being cached here is the content to be displayed, in the domain objects used to display it. In other words, the content is still being rendered by ASP.NET on every request. Since performance concerns were the central business need and much of the content was largely static, output caching would have likely proved more beneficial, even with the drawbacks it had in ASP.NET 1.0.
• Class naming: Naming a class is often challenging as it tends to set the tone for what its purpose is. When you name something with the Manager suffix, it’s likely that you don’t know what exactly the class is supposed to be doing, which means it’s likely to end up doing more than it should. Case in point: The ContentManager is what other parts of the application call to retrieve content, and it’s also what is invoked (through an event) when a cache miss occurs.

What I’d Change

This isn’t meant to be a full design review, so I won’t outline a complete design for how I’d implement this today, but instead offer a brief overview.

In place of ContentManager and CacheManager, I’d employ service objects that exposed the actual domain objects for the specific pieces of content. The service objects wouldn’t use static methods and would be passed into the page presenter objects using dependency injection. To add caching, I’d either use AOP or sub-classes of the service objects that perform caching duties, most likely using keys generated from class and method names and not exposed to the user in any form. This would make it possible to control caching using the IoC container or AOP framework, rather than a host of custom XML and configuration classes. In most cases, the service objects would call out to repository objects that would retrieve the content from the appropriate data store (taking the place of IDataLoader). 

I wouldn’t bother with supporting overly flexible cache settings as the need doesn’t exist. I’d also employ output caching much more heavily and only use the above caching strategy for those content areas with external dependencies, as the requirements dictate.

Closing Thoughts

To be honest, I’ve never looked at any code I’ve written months ago and felt anything better than mild contempt toward it. Perhaps I’m just not that talented a developer, but I suspect that this is probably the case for most of us.

At the end of it all, the dirty little secret is the caching system is still chugging along in production, doing its (not so elegantly designed) job every day. While code fossils are fun as they highlight how you're development technique has evolved, it’s also important to remember that they aren’t necessarily past failures. After all, dinosaurs may not have proven to be the most resilient life-forms around, but they can inform us about today’s world and did pretty well for 160 million years or so.

My earlier post gave my thoughts on what a controller does metaphorically, but I came across a more concrete post about the same topic on Jag Reehal’s Arrange Act Assert blog. Skinny controllers are a key concept in MVC, and really shouldn’t be understated, so it’s a topic I’m likely to continue returning to.

Abstractly, it’s easy to talk about bloated controllers and how dangerous they are, but how do you tell when your controllers are getting fat? One way of detecting controller bloat is the difficulty encountered when unit testing them. As increased testability is a highly touted feature of ASP.NET MVC, many developers moving to it are also becoming interested in unit testing, some of which for the first time. If you find yourself staring at the Visual Studio code editor, contemplating how you should test your controller action methods, it’s highly likely that the controller is simply doing too much. Thankfully, Jag also wrote a good post outlining how to unit test controllers that’s worth your time.

Bloated controllers are likely to yield complicated, difficult to maintain code-bases, which can lead to the same problems encountered in poorly-designed Web Forms applications. Since avoiding such issues is often a catalyst for moving to MVC in the first place, it behooves developers to be diligent and avoid the practices that lead down the same painful path. Adopting a design pattern in name but not in principle won’t deliver the intended benefits and it is still all-too-possible to build a poorly-designed web application using ASP.NET MVC. In other words, the framework won’t rescue you on its own, real, sustained behavior change is necessary.

Put your controllers on a diet, and keep them skinny!