Ruminations

A Brief Glimpse - The Constituency Inheritance Model

Today we're going to do something different. Normally I try to border collie your thought process into seeing your business through my eyes for a little while. In this post I wanted to give you a glimpse into how I see portions of our own business. It's the first post of our A Brief Glimpse series. Hopefully it will be entertaining, a little educational, and maybe even give you some insight into some of the things that we do a little differently. All without chasing you away.

This post will get a little (or maybe a lot) technical. If your eyes start to glaze over go grab a snack and play a few rounds of your favorite app. I'll be here when you get back.

Software development is tedious and complicated. And it can be a painfully boring subject for most people to listen to (unless they’re other programmers). Which is unfortunate, because it can be kind of fun to explain (at least for the programmer). I have been told, by someone who reads this blog but shall remain nameless, that when I explain "programming stuff" it sounds like I'm reading out of an alien textbook. I promise not to share any titles from my Saturnian library in this post.

I'm going to try to explain some concepts and functionality in an accessible way. And hopefully it will be fun for both of us. So break out your babble fish if you need one ...

Workflow is important. Changing someone's workflow can be disruptive and can severely impact productivity and morale in the short-term (and sometimes longer). So, any changes to workflow really need to be worth the trouble.

Here at ElixWare we practice a 'division of labor'. Aimée is responsible for things looking right, I'm responsible for things working right and Chloe is responsible for making sure things get done. It works well for us. It's not always evenly distributed at any one moment (e.g., Aimée can be slaving away on a UI or mock-up, while Chloe is mercilessly cracking her whip, while I play Mr. Know-it-all on Stack Exchange). But in the end, it all seems to balance out.

Many years ago, when Aimée and I started working together, we quickly ran into a problem. We both were used to working alone. This meant we never had to worry about someone else overwriting our files. Since we both used our computers as our test servers we both had a similar development process: bang on the keyboard for hours, get things right and deploy. You can guess where this is headed.

It only took a few times of one of us overwriting the other's changes before we needed a solution. Since I was responsible for making things work right, I was tasked to figure out how to fix it. "Make it so, Number One."

This was an issue that a VCS would not directly address do to the nature of our workflows and the characteristics of the View portion of most MVC (Model View Controller) implementations.

I've long been a supporter of the MVC paradigm. I go back to the days when IBM (via Taligent) called its variation MVP (Model View Presenter) and, more recently, when the MVVM (Model View ViewModel) paradigm made its debut. Anyone familiar with any of the MVC variations knows that the View can become a tangle of presentation markup and logic. This meant that Aimée and I still needed to work on the same files at the same time.

To solve this dilemma - at least for us - I developed the Constituency Inheritance Model (CIM). This allowed each of us to work on the same portions of a project, at the same time. All without changing our comfortable (and almost subconscious) workflows, and without using the same files. CIM works with any kind of implementation, even simple web pages, and not just MVXYZ projects.

CIM isn't a framework or a template system. It's more like Mr. Potato Head. We just put placeholders where we want them to make each page look or work the way we want. Placeholders are used in the View for anticipated content that has a logic or selection dependency, or for content that is used in multiple Views. The Views aren't "processed" like a templating system. Instead, the CIM runtime locates or builds the content for the placeholders automagically and the placeholders expand in place.

The automagic portion is based on settings or content for the client, or the module, or the section, or the page, or the user. Each a shrinking constituency to be served. If the setting or content exists the CIM runtime simply just uses it. If not, it inherits from the previous constituency. "Make it so, CIM."

Since we started using this approach Aimée has not had to resort to strangling me nor contend with a major disruption to her workflow. For us, using CIM just works, which is what every client wants. Even before there was an ElixWare this was our very first solution.

---