One way for Software Engineers/Developers/Programmers to impress the hell out of Managers, Directors and Executives is to confidently shoot acronyms at them in rapid fire. Dilbert is rich with this; since the late 90s I’ve sometimes tossed ‘EIEIO’ into the mix when I heard it being abused.

One of these acronyms is MVC. It’s really simple. See the image on the left? It’s that simple. And it’s not new by any stretch. It’s great for architecture of small systems, and done properly can do well for much larger systems – if you understand how to define the Model, the View and the Controller.

I say it’s not new. In fact, it was introduced in 1978-1979 by Trygve Reenskaug and others for the Smalltalk-76 programming language at the Xerox Palo Alto Research Center (Xerox PARC). You can figure that it has been around almost 40 years, and that it’s from the same era as the mouse and the graphic user interface (GUI).

As a concept, it’s fairly solid – and used properly, it can be powerful. But it doesn’t mean that every system should be MVC – in fact, with application development the way it is these days, a lot of systems probably shouldn’t. Why? If you’ve got multiple application programming interfaces (APIs), you may be going down the rabbit hole into complexity and making software entropy that much more accelerated within your Software Development Life Cycle (SDLC). This article makes that point quite well and offers alternatives, though it stops before getting to some of the conclusions I draw.

So let’s get to the crux of MVC. It’s one of many architecture patterns out there, and the main thing that really needs to be talked about in the context of MVC it’s about implementation – languages and technologies that allow for proper use for MVC. Some don’t give as much flexibility as others.

And MVC isn’t always the answer – more often than not, in the last 2 decades, I’ve seen it used as the straws a drowning application clings to. It’s not bad – it’s not good. It depends on how it’s implemented, and proper implementation in a complex and open system – which describes most – can be outright scary.

A good Software Architect knows these things. A good software architect puts the complete system requirements ahead of the architectural skeleton that is to be and decides on the architecture – while planning for future growth.

Is MVC right for you? I’d say mostly yes. But don’t think it’s new. It’s the architecture that has lasted 40 years and has brought us the applications we have today. Is it the right architecture for the future of your systems? That is a question that should be posed to architects to challenge them.

Your mileage should vary if you’re doing it right.