Get Off My Lawn

Adventures of a Curmudgeon

Spend Some Time With Your Models

Today I had lunch with my best friend. He’s a SQL Server DBA and we used to work together some 2 years ago. We’ve seen a lot of code in our time. Both good code and bad code. Today we were chatting about the bad good we’ve seen. I mentioned I was working on a theory. A theory that predicts the state of an application’s code base. I’m not taking into account developer experience. A more senior developer should be able to design cleaner code then a junior developer, but this, in my opinion, is not always true. My theory focuses on the Models of an application.

To recap, a Model is something important to the application. Some central or actionable concept the application cares about. Having started my career in Smalltalk that’s all I dealt with when I was junior developer. I got it. I get it. Many don’t but claim so. Fat Models make the Software World go ‘round, to paraphrase.

I theorize an application’s support code will mirror the complexity of its models. If the Models are neither clear, concise, nor contain simplistic relationships, the code to support them will reflect this fact.

And I’m not talking about Controller code or routing code (though they’re not immune to a Model’s complexity). I’m talking about the inter-Model communications. I’m talking about the UI controls to interact with the Models (this excludes Ajax too because that can add to complexity of the application independent of the Models).

Over the past few months I’ve been exposed to a variety of applications providing a variety of solutions, from a sports-based social networking site to an application managing a library’s assets. And the one thing that struck me was: the ease to which the application lent itself to maintenance and enhancement was/is directly related to the complexity of its underlying model. The application, in my opinion, that I had the most fun and success with had a clear, concise, and simple Model. It was easy to understand and to see how the Models interacted with one another and used each other to accomplish a task. The application that raised my stress levels out the roof had one of the most complex Models I’ve ever seen. It was very difficult to see how the Models interacted with one another to accomplish a task. It was also difficult because the Model contained many complex, and inter-linked relationships; the UI controls to deal with this complex Model were themselves complex and difficult to follow.

I don’t know about you but I get paid to create solutions. The longer it takes me to understand the problem space, the longer it takes me to create a solution - simple physics. And don’t get me started on developers writing ‘Too Clever’ code - go impress your friends, not your employer/client because the next guy won’t get it, guaranteed. For those that have known me for a while know how I always preach ‘Simple’. Applications naturally get complex. That’s what they do when they evolve from customers asking for more features. Refactoring is your weapon against the complexity. I digress.

The Application’s Model is the story the application is presenting to its end-users. Sometimes that story will be complex, that just may be the nature of the problem space. Often, I believe, that story can be simplified. If not: Document why that complexity exists. If the Model is the story, Comments are those notes in the margins; essential to clarify or compliment an idea. Remember, application code spends more time getting maintained then getting created. The next guy will not be at the level of the original developer, often the next guy is a junior member of the team. Be Kind - Document. You’re bound to be the Next Guy sometime in your career.

Is your Application’s Model fit and trim or not?