Explain MVC to non-programmers

Question

I have a need to explain MVC to non-programmers. Namely, to managers of other departments, in the context of progress report. One of the things I do is refactor our codebase towards MVC separation.

What is MVC separation they might ask? Why is it needed they might ask?

After reading a fairly technical answer like this: What is MVC, really?, I am not entirely satisfied, since I will be talking to non-programmers. They may nod their heads but they probably will not understand what it is and why it is needed.

In reality, I don't fully grasp what MVC is other than "separation of concerns, duties, functions, classes, blocks, tasks, things, in order to improve flexibility of making changes to the software". Separating database from view and view from business logic using techniques like DI and OO tools and techniques is something I consider to be MVC separation.

So next time you are explaining MVC to a non-programmer who has background in sales and accounting for example, what would you tell them?

Answer 1

You don't explain MVC.

What you do is explain that this is a restructuring of the codebase.

A restructuring that simplifies the codebase and therefore enables the developers to make faster and better changes to bug reports and feature requests, with less bugs.

They don't need to know the technical details, just why it was done, what was achieved by doing it and how the business benefits.

In other words - speak their language to them.

Answer 2

While I endorse the gist of Oded's answer, that you should explain technical projects to business managers in "their language," I have a qualm about "they don't need to know technical details, just why it was done."

If you are in a project or investment review meeting with department heads, and you declare "this is what we're doing," they may want to ask "Umm...why? That seems like a big investment of time and energy. Could you give us a little more understanding what you're doing and why?" That seems an eminently reasonable question. You don't want to be caught out in a position of "Well...it's complicated." or "No, I can't really explain it." or "Don't worry yourselves about it." The more senior the staff you're doing the project review for, the less likely they are to let "it's just stuff I can't explain well" fly. Better if you can go at least one level deeper to make others feel comfortable that 1) you know what you're doing and 2) this really is a reasonably-considered effort/investment.

So, have a sketch of MVC in your hip pocket, ready to go. Something like:

"It's a bit technical, but... MVC divides code into Models (responsible for the core data and business logic), Views (which displays the data), and Controllers (which handle user interactions and updates). It's a proven architecture--possibly software engineering's most successful "design pattern." I know it might like seem like "just some plumbing," but to handle all the requests coming in, we need a stronger foundation. This will put us on the right footing to build new features and resolve bugs faster."

Even if they don't fully understand MVC at the end of it, and even if you had to over-simplify to make it comprehensible ("break some eggs to make an omelet"), I wager you will find it much more comfortable to have an explanation ready than to have to say "I can't explain it" or "you aren't qualified to understand it" to senior managers.

Answer 3

in order to improve flexibility of making changes to the software

Managers are interested in the end result. The less technical they are the less likely they are concerned with how you get there. MVC is very common, popular and proven.

When change requests are made in the future, you can let management know they can be made easier and faster. Everybody likes to hear this.

It is a common strategy, so hiring new developers shouldn't present a problem. In fact, you may attract better developers who are strong proponents.

This is all going to be very difficult if there are many pressing issues in this particular project. They may not be wiling to take a step back so you can take two steps forward. On solution may be to wait or implement in smaller pieces.

Answer 4

• Model - Wires/electricity
• View - Light Fixture
• Controller - Light Switch

Relatively easy to switch out components (light fixture, light switch/dimmer). Maybe not so much the wiring, but still can be done without effecting other components. Everyone should be able to visualize that in thier head, even marketing/sales types. (Clear separation, etc.)

Now tell your boss/co-workers that in our application/system the switch is embedded inside the light fixture and the light fixture is wrapped around in copper wire. Now imagine trying update the light fixture, switch, or wire. Very costly, impact to other components very high and perhaps dangerous to do without breaking something else.

MVC is applying a pattern to the code base which turns the jumbled (but working) mess into something where changes can happen faster and easier with less errors.

Answer 5

An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two.

The best rubric ever: "We need SMART Models, THIN Controllers, and DUMB Views"

As with other software design patterns, MVC expresses the "core of the solution" to a problem while allowing it to be adapted for each system. It is better seen as a concept instead of a specific implementation. There are many implementations of the concept.

All MVC variants use the same division of components, but usually they differ in how those components interact.

For those of you who are not aware, MVC was originally described in terms of a design pattern for use with Smalltalk by Trygve Reenskaug in 1979. His paper was published under the title "Applications Programming in Smalltalk-80: How to use Model-View-Controller", and paved the groundwork for most future MVC implementations.

Answer 6

I halfway-agree with Oded - learning how to convince your non-technical peers and managers that what you are doing is important and useful, without explaining the gritty details, is a necessary skill that you would be wise to develop.

However, I believe that having the ability to explain complex concepts in simple terms actually helps with that - one problem non-technical managers often have is that since they have trouble understanding exactly what it is the tech folks are doing, they have a tendency to mistrust them. It's just human nature: it's easier to believe that something you don't understand is useless or wrong than it is to put your faith in it. Therefore, if you can make concepts easy to understand at will, you can use that whenever you need it, and over time, your non-technical managers will learn that they can understand it if they want to - you aren't pulling one over on them - you are just sparing them the details for their own sanity. They will trust you more.

That aside, let's answer the question:

I find it useful to use analogies that business people understand. For MVC, I describe it as a business.

• Models are responsible for the business logic and data - they are the things that define what the program does and the details of how it does it. If the program were a business, then models would be the warehouses, factories, workers, and capital equipment. They would also be the lower-level managers that make sure rules are followed and policy is enforced.
• Views are the presentation layer - they show users what is going on in the system and provide a means for interacting with the program. If our program were a company, views would be like the showroom floor, the sales booth at the trade convention, or the sales reps. They display options, provide user-friendly information and feedback, and take requests back to the company.
• Controllers are the coordination layer - they make sure that information gets from the models to the views and vice versa, and that everything works together to do their job. If the program were a company, then controllers would be the mid- and high-level management. They don't get too involved in the details, but they make sure that the right people have the right tools to do their jobs, and they approve or deny high-level decisions. They provide the overall direction so that things can work together.

The benefit to explaining it with this analogy is that a good manager will see the wisdom in separating concerns this way, and might decide that they should be more controller-like, and not get too involved in the details in the future!

That hopefully will answer the "what" - the "why" is also easy with this analogy:

Imagine an ideal company, where each department is responsible for one set of tasks, and knows that it will always have the resources it needs without having to worry about what others are doing. A sales rep finds a customer, gets their order, passes it back to management who approves, and then it goes to the warehouse/production/engineering for fulfillment. Feedback is direct - no one else needs to get involved unless there is a problem. That's a good MVC design - each part has a job, and it doesn't have to worry about other parts. That way, it's easy to change if we need to. In a non-MVC design, responsibilities aren't clear. The sales rep may try to modify the product when the customer asks for something different. Or they might give different prices depending on how they felt that day. The CEO might be down on the factory floor messing with the production line, when he should be worried about how to get a more reliable supply chain in place. The warehouse workers might be out on the sales floor talking to customers when they should be fulfilling the orders that were already taken.

In other words, good MVC design lets each part focus on one thing, so that it can do it right - just like a well-organized company.

**Disclaimer - if your company is poorly organized, they might get offended by this. In that case, you will need another analogy. You might also need a different job.

Answer 7

Benefits of MVC is primarily in the separation of concerns:

It lets people concentrate on what they do best.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

It lowers costs because intertwined systems require staff to be either experts in all of these areas, or you are more likely to have problems when a change on one area affects the others.

Provide real-life examples of MVC architectures: Cell Phones, Desktop Phones, Skype, etc. Changing the View (type of dial pad, speakers, mics) doesn't affect the model (the audio signal), the controller is the circuitry in the phone that translates sound waves into audio signals.

Answer 8

I would tell them that MVC separates my concerns.

My first concern is the code logic - what I do behind the scenes to make the website perform the actions they want it to.

My second concern is the business logic - what they (the user) want the application to do.

My third concern is how the site looks - The page they visit to do what they want.

(I woudln't tell them this next part) So, in order, my explanations were for the Model, Controller, and View.

Answer 9

Explain the advantages

I would explain MVC in terms of business benefits. Your managers will be able to understand this, and will get on board if the advantages are convincing.

MVC allows you to break down your application into sensible units, each of which exists independently of the others. You get clean, maintainable, testable code, and potentially code reuse between systems.

The Model

Each model encapsulates a single type of business information, for example, a customer record or a product, along with all related business logic.

Separating this out allows you to easily test your business logic in isolation from other parts of your application.

You can also easily extend the application by adding additional models, it's very modular and clean.

Each model in theory can exist independently of the others. You might consider enforcing this by using service objects to handle relationships between models. You can swap out models without affecting the rest of the system.

The View

Separating out your view allows you to easily update your front end without breaking the underlying back end.

You can give your front end code to another developer without necessarily giving them access to the whole system.

You are also free to create alternative front ends that work with the existing system. You might show your data as a mobile app, or an API, or a PDF, or an Excel spreadsheet. You can do this without hacking into the rest of the system. You're less likely to break things accidentally. You can readily create integration points for existing systems to hook into.

The Controller

The controller wires the models to the view. It keeps everything separate. You can wire in a different view very easily. If you change your model code, the view doesn't even need to know.

Other Advantages

It's a common pattern. Other developers will be able to understand your code and work on it. If you return to your code years later, you will likely be able to understand it and make changes. Your code will be less likely to become another legacy headache for a future developer.

Because everything has a place, it's much easier to produce clean code. The risk of spaghettification is dramatically reduced (though not eliminated). Your code becomes maintainable.

Because everything is modular, you can test parts of it in isolation. Your code is testable and less likely to harbour bugs or security holes. Future upgrades will be much easier as you will be able to easily test the whole system.