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?](https://softwareengineering.stackexchange.com/questions/127624/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: 
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.
> 
> 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.