Our development team uses Spring MVC. It is an open source web application framework for use with Java. One afternoon, I found myself between meetings and decided to read the Spring MVC book. I quickly discovered that I had now eliminated Spring MVC development as a career possibility. Spring MVC is supposedly a “light weight” development platform (although the book was hundreds and hundreds of pages thick). That means there isn’t a lot of fancy features and switches you can toggle one way or the other, or which can get botched up by the unsuspecting developer. My project management mind thinks, “less risk.”
MVC stands for Model, View and Controller. There are other modules that help with batch processing, security etc. but we aren’t using these at this time. The framework causes a separation between business, navigation and presentation logic.
There is a controller (the C part) manages navigation. The controller acts as a gate keeper for requests.
The model (the M part) sits between the controller and the view and contains the data needed to render the view.
The view returns the response. (The V part).
Now I don’t really care about any of this. But what I do care about is what this stuff means to my project. So the PM type question to ask is, “How many models? How many Views and how many controllers are you guys planning on writing?” When they get done staring at you they will go off into a room and come back with a number and a description of what they are doing. Now that has project management value.
Because these three layers are broken up, you can break up the testing: someone tests the business logic while someone QAs the user experience. This is a feature that would endear itself to a PM. I can put 2 people on this if I need to without them running into each other.
The last nice thing about this framework is that when you get new staff that may not be up to speed, you can have them focus on this framework as a way to get up to speed. It is relatively small and the books are pretty straight forward.