Where is Bill and Ted? Do You Hear Those Air Guitars?

Team. This is definitely an "excellent" adventure. As corporate software engineering teams gain collective experience over many project life-cycles, they can become more productive with each iteration of this cycle. And, as well known, productivity follows quality. Quality is enhanced as project teams "mature" and become more "capable", producing repeatable, measured, managed, and optimized projects. They can leave behind those "big bang", "one time" ad hoc experiences where software is created that can only be used in a limited range of production instances.

It has been said by software engineering researchers that developers much like teams have a process, a personal one. And, one could reason that this personal engineering process can follow a capability maturity model (CMM)-like evolution.

This has been the case for the author with "simple" web-based controllers. During the late-1990s, in the first half decade of the WWW, he spent many hours writing common gateway interfaces, mostly using C on a UNIX platform. It was a frustrating experience. Although he is not a perfectionist, he is somewhat of a "purist".

Those early common gateway interfaces had a "poor-quality" architecture. The various concerns: the view elements composed of HTML and related technologies, the logical action of the controller, and the interaction with the entity classes where much like a "co-mingled" plate of "goulash". It was not "spaghetti" code, but it definitely did not have well-defined layers like a "lasagna": cheese, noodles, meat sauce, cheese, noodles, meat sauce, etc.

This made development tedious and frustrating. Yet, as a junior engineer with very "little" seniority, management would not consider the author's advice about "properly" structuring the controllers and partitioning the concerns. More emphasis was placed on using certain "buzz-word" technologies than building the company's products well.

Yet, the author felt that he could build a "small, simple" one well the could be the cornerstone of the company's web-based systems that secured financial systems for a Fortune 500 insurance company and a securities firm. But, he simply put his ambitious goals aside so he could keep receiving a paycheck.

Although not a "steady" effort over the past couple of decades, much thought has been given the idea of building a reusable "general-purpose" controller framework. For one, a controller is basically a "logic-switch" that sits between the presentation layer and its related view technologies and the model layer with its associated entity-class technologies. A controller represents that middle-ware glue that binds the view and model of a layered model-view-controller architecture. As such, it must be flexible and malleable.

It is an important enough software structure that it be studied, refined, and built well. For one, it, like the impostor Jared, has a number of talented personas. This includes a command shell, formal language script interpreter, network-based protocol handler, and etc. The controller is a powerful paradigm.

And, as part of future Rosetta Stone efforts, we might morph our "general-purpose" controller for use as a kernel for a command shell, interpreter, and "network-based" protocol handler.

Be a Bird-Brain. Hunt, Peck, and Think. It Makes for Better Code and Lowers Stress Hormones!