A common occurrence many development teams will encounter is a where an older system not designed to scale well, will need to consider scale to support business demands. Businesses need to move quickly and purposefully to cope with consumer demand upon services as well as innovation induced development to compete within the market place.
It could be that your current system was designed to meet previous business goals and the extent of the specification was simply to complete a given task. You might be finding that recent business demands are taking a great deal of time to implement and that the smallest change is having huge impacts on the existing code structure. This could be as it is in so many systems, a result of tightly coupled code which is infected with design debt, or it could simply be that the original design of the systems structure didn’t consider growth and re-usability beyond the scope of the original spec.
If this sounds familiar to you, you’re probably spending a great deal of time on system maintenance and testing. The smallest changes are having huge impacts not only with relation to system integrity, but having a negative impact on the professional image of the development team. Depending on how far you have gone down this road, the business could be seeing IT as a wasteful, incompetent resource.
As you’re reading this post, it is likely that you’re thinking that to make things better you are looking at introducing MVC (Model, View Controller) into your system architecture. This MVC structure maybe something that is being encouraged by a chosen framework or simply a structure you wish to introduce into your existing system whilst refactoring your code. Either way to gain project time in most cases the business have to recognise the need for such a change and allow resources to be allocated to move towards this place where the grass is said to be much greener.
Now you are in a situation where the business already blames development teams for slower production times and pretty much for all problems and bugs that are inherit from a system which may have been subject to the ‘Big Ball of Mud‘ scenario. How can you go to the business asking for more time and resources to work on a project which unlike a product development has no physical delivery. After all if you are moving your system to MVC and/or using a framework there maybe no physical difference in the end product initially. Why would the business want this? Where is the ROI?
Respect the old code and the business
When approaching the business it’s best to be honest and upfront. There is no gain to be had blaming individuals for the current state of the system. It not only looks as if you’re diverting attention, but your colleagues aren’t going to appreciate you pointing the finger away from yourself in their direction. You should also remember at this point that it’s this system which has supported the business to date and is likely to be the same system that is supplying the current revenue stream. Although the system may need work, it has done it’s job to date.
Don’t hide the facts and don’t cushion the blow
The first rule here is to respect the business and tell them the truth. I’m sure you will be surprised to how much they actually know and that could be your first factor in common to working together towards the solution. There are plenty of examples out there on the web of successful companies who are and have been in the same situation of introducing MVC and/or Frameworks. It would be a good idea to use some of these examples as this will not only provide a knowledge pool of what did or didn’t work well, but will reassure the business that the problem the system is suffering is very common and there are clear paths forward. There is no gain to be had by raising an alarm defining how bad the current system is without researching and demonstrating clear ways forward. This won’t aid your case of supporting the development of a new structure. Use real cases and put forward some other success stories where this change has been successful to inspire the business.
How did we get into this mess
The old saying ‘Learn from your mistakes’ is relative to this exact moment. However to learn from your mistakes, you must recognise that you have made mistakes.
There are thousands of reasons why systems can incur significant design debt. Many of these reasons are comforting to know as they can happen naturally by the very nature of simply being active within successful business. It’s very likely the reason your looking to for a framework or MVC structure is that you want to support growth. Business growth has taken you to this point in time and that business growth is a commendable asset and a reassuring factor to be presented with.
Common factors of business growth that influence systems and incur design debt could be the following:
- The business has grown so fast, very little resources have been available to maintain the design.
- Corners have been cut in development to ensure products are released in a short time and therefore generate income quicker. The short cuts have never been revisited and therefore they become permanent. Additional development therefore have inherited the previous problems.
- The purpose of the system today is very different to when it was originally designed and limited effort was proposed to make the transition. Instead quick fix cultures were applied to change the identity of the system.
- Customers have become larger. As a service grows you might have moved from B2C to B2B or both. This can drastically change the demands on the system and the original business intentions/system did not consider this change or scale of change
- Limited knowledge available. In fast growing businesses the developers are expected to know all the answers without been given time to research. Therefore applying solutions are done through a limited knowledge base which is not given time to increase through training and investment.
No matter what your reasons are it would be a benefit for IT and the business to share and understand some of the reasons. Both sides understanding these will help prevent mistakes being repeated in the future, but will also contribute towards design and research to be key elements in future solutions.
Remember if your system is cracking at the seems as it can’t scale well, this could be because the business is growing fast. You would do well to respect the business for this and at the same time use this fact as a reason for current system problems. If the business is successful it’s likely they will take this on board and appreciate that speed of growth has affected development. This could provide you with the opening of working with the business to get the systems into a more robust agile condition.
Introduce MVC
Remember the business are non-technical and using jargon like frameworks and MVC is likely to confuse the listeners and as a result put up barriers. The reason you are proposing MVC as a solution is that you probably want a clear system structure which will be provide an environment which is easier to develop and maintain. However before you start getting this message across you need to explain what MVC is and what benefits it will offer.
Define the existing structure clearly
One of the reasons you might be looking for an MVC structure is that your current code structure involves code where the interface incorporates business logic, or the business logic is coupled with system logic and so on. Ignoring the reasons for this as we have briefly mentioned them above, explain this is the case to the business. The better you get the business to understand this situation the more likely they will sympathise with you and understand why there is higher maintenance times and deployment issues.
Some further reading can be found here:
http://en.wikipedia.org/wiki/Spaghetti_code
http://www.laputan.org/mud/
http://www.codinghorror.com/blog/archives/000589.html
Define MVC in layman’s terms
Remember you’re technically minded and close to the code. MVC to you is as clear as day, but saying to the business ‘Model, View, Contoller’ could give them the impression that you are suffering from some form tourette syndrome. MVC won’t mean much to the business even after you define them in relation to the code. To get the business to understand why this is the answer and least of all what it is, can be more of a task than expected in my experience. Even some fellow developers have difficulty understanding this on occasion.
To get the listener to understand what MVC is and why it works what I have tried in the pass is to apply MVC to a different industries where the listeners have had more involvement. An example that has worked for me in the past in a comparison to the property or even the vehicles. Most people have had dealing’s with builders, carpenters, plumbers, electricians or have watched the flood of property shows on the TV. This experience is a good platform to use and to explain why separation such as MVC works. I know you’re probably thinking that won’t work as it’s not the same as in software, but remember you’re not trying to train the business to become developers or have an in depth understanding of MVC, simply explaining to them that separation in production is required and that’s what an MVC structure offers.
To give an example of how you could describe this I have very briefly explained how separation works in property. Keep in mind this is focused on using the system not developing which could be a completely different angle of explaination.
View
The view in MVC is the presentation layer. This is what the end user of a product will see and interact with. A system can have multiple views of all different types ranging from command line output to rendered HTML. The view doesn’t consist of business logic in most clear designs. The interface is fit for purpose and is the area of interaction. Therefore you could simply output HTML for consumers to interact with or output SOAP/XML for businesses to interact with. Both use the same business logic behind the system otherwise known as the models and controllers.
In the world of property you could think of the view as the interior of a property or the outer layer of a property that the inhabitants interact with. The interior can be customised for purpose and the same property can have many different types of tenants. For example a property of a particular design could contain residential dwellings. The same internal space could easily be used as office space, where although in the same property has a different purpose. However the property structure is the same. Therefore the environment in which the users interact does not interfere with the structure of the building.
Controllers
The controller is where the magic happens and defines the business application logic. This could be where the user has sent a response from the view, then this response is used to process the internal workings of the request and processes the response back to the user. Taking a typical response where a user has requested to buy a book. The controller has the user id, payment details, shipping address and item choice. These elements are then processed through the business logic to complete a purchase. The data is passed through the system into the model layer and eventually after the entire request satisfies the business definitions, the order is constructed and the user receives their item.
If we compare this to a property, we could compare the ordering of a book online to turning on a light switch. A tenant will flick the switch to on just like ordering a book. The switch itself is an element in the view layer which sends the request to the controller just like clicking a checkout button on a web site. The business logic in this case is what the electrician installed and are embedded within the property designs. The switch is flicked, which completes the circuit. Electricity runs through all the wires including the fuse box straight through to the light bulb. Just like the user receiving a book, in this case the tenant receives light. The whole process behind the scenes involving the electricity cabling is not visible to the the tenant. They simply interact with the switch within the space and from there the controller handles the request.
Models
The models in MVC are the bottom most layer and handle the core logic of the system. In most cases this could be seen as the layer that interacts with the data source. In systems using MVC, the controller will pass information to the model in order to store and retrieve data. Following on from the example above controller definition, this is where the order details are stored. Additional data such as stock levels, physical location of product of the book amongst many things are all stored here. If that was the last book in stock ordered, the next request for this item may check if it’s available and disallow the order as the item is no longer available.
Sticking with out example of turning on a light switch, this level in our structure could be the electricity supply. When the tenant flicks the switch, the internal circuit must request electricity to power the request which is similar when the user requested data from the database, as in data is needed to process a request. If the dwelling isn’t connected to an electric supply, it cannot complete the process.
Business benefits from using MVC
After you get the message across explaining what MVC is, you will then have to see what benefits can be obtained from it. I’m not going to go into a huge amount of detail here are I’m sure you can apply benefits more accurately which are directly related to you actual situation. To list just some of the common benefits of an MVC based system here are a few examples:
- Different skill levels can work on different system levels. For example designers can work on the interface (View) with very little development knowledge and developers can work on the business logic (Controller) with very little concern for the design level. Then they simply integrate together on completion.
- As a result of the above separation projects can be managed easier and quicker. The designer can start the interfaces before the developer and vice versa. This development process can be parallel as opposed to being sequential therefore reducing development time.
- Easy to have multiple view types using the same business logic.
- Clear route through the system. You clearly know where there different levels of the system are. With a clear route of the system, logic can be shared and improved. This has added security benefits as you clearly know the permitted route from the data to the user and can have clear security checks along the route.
- Each layer is responsible for itself. (Relates to point 1) This means that you can have clean file structure which can be maintained and managed much easier and quicker than a tightly couple system where you may have lots of duplicate logic.
- Having a clear structure means development will be more transparent which should result in reduced development time, maintenance problems and release cycles if applied properly.
Get the message across
If you’re still reading this article you maybe either thinking the example above is a good idea or that it’s just plain silly. No matter what you’re thinking, the goal here is to get your message clearly. If this example doesn’t work for you, try finding a solution which will have the same affect. The point is for the business to support you and to consider repaying the design debt you will need them to understand what problems the current system suffers from and how you can improve things. MVC is just one of many ways forward, but they will need to understand MVC to give you the green light and have time to implement it and factor it in future projects.
This has been written from my own personal approach. However if you have something to add to this post in order to give it value, please provide some feedback. It will only improve things for the next reader.
Related Links
Working-Effectively-Legacy-Robert-Martin
#1 by Anon Coder - June 28th, 2009 at 22:21
Great article! Really explained MVC well. The examples you mentioned put things right in perspective for me. I came across this at just the right time in my decision making.
Thanks
#2 by Leon - July 4th, 2009 at 00:03
I disagree that any of this is necessary for three key reasons.
1) It’s not a business decision unless you’re selling source code. It’s an implementation decision. I have never once had a non-technical business come up to me or my team and ask for a feature or fix, and then followed it up by saying “oh, and make sure you use **this** IoC container and use the Visitor pattern to parse our data files”
as I say, those conversations just don’t happen. Thank god. Can you imagine?
2) MVC alone is not a magic bullet that fixes broken software any more than Ruby on Rails is by its own virtue. What you want to build is better quality, more reliable and maintainable software. Now MVC alone doesn’t give you that. Good architects, good project managers and good programmers do. MVC is one of many ways that can be achieved. But don’t forget it’s equally possible to build shockingly risible MVC systems too. Enter the architects and PMs.
3) If it’s new to the team they will still have to learn the new technologies or techniques, or you will have to employ new people who do have these skills. This is doubling your notional cost to the business.
Oh, and there’s a possible 4) You are in danger of alienating the business by trying to explain esoteric software engineering concepts to them. They don’t care. They want an IT department that **listens** and then **helps**. By forcing non-technical people to try to understand this you’re potentially driving a political wedge between you and the business that will result in them never taking you seriously.
Seriously, I wouldn’t even mention it to them. Rather than this endeavour of trying to explain a software architecture methodology to people who just want easier and better ways to do *their* jobs, you’d be better off concentrating on getting requirements *from* the business, rather than giving irrelevant ones to it. I expect if the system is that bad, the business is well aware it needs addressing and they’ll be receptive to any suggestion to tackle it. Especially one that the business feels like its in control of.
#3 by Craig_Strong - July 4th, 2009 at 09:24
Hi Leon, Thanks for the feedback. You raised some interesting points there most of which I agree. I think however there is a bit of confusion with probably the way I indicated explaining to the business. When I described the above, I don’t mean the business literally in terms of persons far away from technology. This could like say alienate the business and break down communication. What I meant by business is more on the lines of business representatives such as business analysts and project managers, or persons that have more of an invested interest with the development section. These are the people declaring timescales and can take part of the blame in the event of failure, so often ask questions starting with why? If they are asking why something cannot be re-used or why can’t we separate some of the current logic, this is where an explanation might be from a very high level. These maybe the same people that will need to allocate development time to create long terms plans for the business and are aware of costs and other such factors.
However like you state MVC is not the definitive answer this is just an example of structure. Through lack of understanding or poor implementation, MVC could easily cause problems just like any other structural proposal. It’s more of a theory based solution to consider creating maintainable systems as opposed to the answer to all problems if that makes sense?
Again thanks for the reply, that has certainly added some value to this post.
#4 by John - May 12th, 2010 at 12:24
Do controllers have business logic? I think this is about style of design, but controllers are supposed to only redirect views?
#5 by admin - May 12th, 2010 at 20:19
Hi John, thanks for posting that question. You’re right in your assumptions that controllers shouldn’t contain ‘core’ business logic. In theory you should always be looking to have Skinny controllers and Fat Models. However as controllers can have sequences/calls to models in the form of actions, you could interpret this as ‘Business Logic’ to a certain degree. The business logic could be seen to be the throughput from the controllers to models and back to controllers again. This is why I tried emphasising ‘Core’ business logic within the model to try and separate it a little. If you weren’t to consider business logic as starting at the controller and take it literally then the theory would suggest business logic only sits within the model. Maybe it would have been better if I had said ‘application logic’ within the controller and ‘business logic’ within the model to make things clearer.