Functional Design Patterns

Applications have patterns – ways of doing things that have stood the test of time. These aren’t object modeling patterns, about which books and books have been written, these are…best practices for how to solve a particular type of functional problem.

Around my city, you see a certain style of house with the garage pushed forward toward the road so the architect could fit living space behind it. You see this home style coming from many different architects. Why? Because it has sufficient benefits to outweigh the drawbacks. It’s a pattern – a best practice that offered the most benefits with the fewest drawbacks and was thus repeated.

In content management, sufficiently mature systems tend to fall into patterns as well, no matter who makes them. An example –

When your content management app gets mature enough, you’ll probably end up with a content tree, or taxonomy – a recursive structure whereby an object can be a parent of another object. I’ve seen this same functional design pattern in systems from Interwoven, Documentum, eZ systems, Zope, etc. If you work with big content management systems long enough, you eventually come to realize that that’s just the right way to do it – the design that gives you the most benefits with the fewest drawbacks.

So over the years, I’ve learned to build content management systems this way from the start, because I knew I was going to end up in that pattern eventually. Why? Because a lot of people have been doing content management for a long time, and it’s become obvious that content just works well that way. (The underlying theory of a content tree is another post entirely – I promise I’ll write it next week.)

Here’s a more in-depth example –

I have a client right now who needs a Web-based calendar. Now, these things have been done to death. But did anyone…take notes? Did anyone examine how a calendar works from a language-independent standpoint and determine how to model the concept of events occuring across time?

Put another way: events and time have been with us since…well, forever. Before computers, certainly (yes, Dave, it’s true – time didn’t begin on February 24, 1955). So, we should be able to sit down and model an electronic calendar without any consideration of languages or platforms, right?

Joe and I did this for a few minutes over lunch. We discussed the concept of a calendar while waiting for our burgers, and we came up with these random considerations you need to be aware of before you start building an electronic calendar.

• Events can be of two types: point and range. A “point event” is a singularity – it happens at a single moment in time (“applications are due at 5:00 p.m. on Friday”). A “range event” starts at a certain time and ends at another time.

• You need to pick a base time unit for your calendar. This is the smallest unit of time into which you’re going to group events. For our purposes, we’ll take a day – when we hand our presentation code a bundle of events, the smallest unit will be a day.

• Events cannot recur during the same unit. If you teach Computer Science 101 at 9:00 a.m. and 3:00 p.m., that’s not recurrence – that’s two separate events: a morning class and an afternoon class.

• Now, the previous points mean that an event can have one of four states in relation to our base unit of time. An event can:

• “happen” during that unit, meaning that the start and end of the event is within the unit

• “start” during that unit, meaning it will begin on the current unit and end on another unit

• “continue” during that unit, meaning it began on a previous unit and will end on a later unit

• “end” during that unit, meaning that it started on a previous unit, and ends on the current unit

So when our calendar groups events into a unit of time, it will group them into events that (1) happen, (2) start, (3) continue, and (4) end during that unit.

What’s above barely scratches the surface. Just wait until you start to consider recurrence – the implications get overwhelming pretty quickly (we identified “tight,” “loose,” and “irregular” recurrence within a few seconds, not to mention “overrides,” “forces,” “suppressions,” etc. We could be here all day…).

But, this isn’t my point. My point is that the structure of a calendar as we discussed above has not changed because of computers. Events have been relating to time in the same way forever. And this relationship is not going to change. Ever.

So, what someone needs to do is create a comprehensive, all-encompassing data model explaining how events and time relate. Essentially, design the ultimate calendar, then separate the “eternal core” of a calendar from the implementation, and present a language independent description of how you create an electronic calendar. What pieces of data does an “event” expose, and how do they relate to the concept of “time”?

The idea is to stop re-inventing the wheel from a functional design standpoint. You capture this model, then let anyone implement it in whatever language they like (even ugly, procedural code), incorporating whatever depth of the model as they want. But no matter what language an implementer uses, or how deep he or she wants to go with it, the best practice of how a calendar is structured and works is unlikely to change much.

The bottom line is that developers fall into ruts. This isn’t a bad thing. More often than not, we fall into ruts because they’re the best way to do things. These ruts don’t care about languages or platforms – they completely transcend technical concerns. They’re more concerned with the eternal core of a problem.

We need to identify and document these ruts, these best practices, these time-tested solutions. Being able to read a functional design pattern before you started a similar project would be like talking to a developer who has built 100 of the same type of systems, and listening to him tell you all the dead-ends he went down, all the false leads that failed him, and finally, all the functional patterns that worked so well that he found himself doing them again and again in successive projects.

My passion is content management, and I’m thinking it’s time for a public wiki so we can all have a big discussion on how content works from a functional standpoint.