Craig Strong

When first introducing scrum into the workplace some time ago, many people had strong
views on what agility meant and certainly had some strong opinions on how Scrum should
be implemented. Some of these views created divides between teams, people and
processes. After quite some time re-factoring processes, communicating and refining
techniques everything started to take shape. We started getting to grips with TDD, had a
continuous integration server set-up, introduced product backlog tools to manage groomed producted backlogs and really
progressed well with the quality in writing user stories. In hindsight it was clear that what
we started with was far from what we needed and ended up with.

Although we seemed to follow the standard practice well and could see progress all
around, the first and largest project we started which was the project we introduced scrum
to the company with, was late and far from agile. Management had little confidence in the
project and were concerned that every time a change was made, bugs would surface into
the product backlog. Not only was the management concerned that change was
problematic, but confidence was so low that there was a fear that introducing new features
would put the launch of existing features at risk due to the possibility of new bugs
surfacing. This was not a good place to be for anyone!

Looking at this project many things went wrong, but most had been fixed. After a few root
cause analysis exercises we looked at the main symptoms. It was quite obvious the main
reason it was late was because the project developed an incredibly long tail of bug fixes.
“How could this be?” we asked ourselves, we have TDD in place, we have peer reviewing, a
pretty decent “done done” list and a few other XP practices in place. We knew bugs would
always surface as this is the nature of software, but this was a case where you fix one bug
and introduce three more. I began investigating the problem further, this was clearly not
the way to do it! I regained my title as Scrum Master in the problematic project and started to observe the team.

After a few hours I started to see the root cause of the problem. When the team were
tackling the user story they would notice bugs. However the bugs were “not directly
related” to the user story being worked on. As a result of this, the team would look down
the backlog and see a user story which covered the area where the bug surfaced. Then
they would negotiate with the product owner not to fix the bug in the existing user story, but
to leave it there and fix it when that user story surfaced. Apparently this would be quicker and it was a way to by pass the failing tests and negotiate a way around the “Done Done” list. After seeing this the penny truly dropped.

The problem with the above was that we were using an agile process with a waterfall
approach to the product backlog. After each retrospective taking this approach meant the
product was not shippable and the sprint reviews would introduce new directions for the
product. What this meant was that the user stories in the backlog which would fix the accepted bugs, may be removed, de-prioritised or never tackled. Therefore this meant that additional user stories had to be created to solve the debt which should never had been
there or that velocity would continuously decrease due to an ever increase bug debt.. The value of these user stories was very low. This exposed the fragility of the process and  also enforced why it is so important to ensure each user story is shippable by adhering the a clear, well defined “Done Done” list.

Following the identification of the above, we came up with a strategy to resolve the issue.
The Scrum Master (Myself), had to enforce a strong bug stance in accordance with a more
detailed “Done Done” list and flush the bugs out. Initially velocity went down considerably, but it was a
true velocity. After a few sprints not only would the bugs be flushed out, but the product backlog was much healthier. Managementʼs confidence started to rise again and although less was being delivered, what was delivered was shippable. After just a few sprints velocity started to rise and the long tail of bugs added to the product backlog started to diminish.

To conclude, we learnt at our expense that quality is a metric that is controlled by the team
and expected by the client. Putting off today what can be done tomorrow is not the path to
agility especially when this is quality. Doing so will increase the likelihood of project failure and make the product fragile.  The product backlog is a living entity subject to
constant change. Unlike waterfall the path is not linear and if it is, the path is not agile.

It surprises me how many people don’t fully appreciate what cross-functional teams (CFT) are or what they aim to achieve.This ends up creating problems, increasing costs, lowering moral and hindering progress. However outside the business environment many people fundamentally know the principles of a CFT, particularly anyone who has an interest in sport. The same people are sometimes incredibly passionate team players and go over and above to help their local soccer team achieve, even if this means playing in different positions just like the generalised specialists of Agile. However in a working environment, working with others outside their department is a chore and often avoided by some. Therefore why is it difficult to solve the same problem in business environments. Before we look into more details of CFT’s lets look at an official definition of what a CFT is :

“A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. Typically, it includes employees from all levels of an organisation. Members may also come from outside an organisation (in particular, from suppliers, key customers, or consultants).” – http://en.wikipedia.org/wiki/Cross-functional_team

If you were to slightly reword the definition above, you would end up with a close definition of what a soccer team might be :

“A soccer team is a group of people with different skills working toward a common goal. It may include players in attack, creativity, defence and man management. Typically, it includes players from all levels of physical and mental ability. Peripheral members may also come from outside the team (in particular, physios, trainers, fans, or sponsors).”

Although that is a pretty limited comparison, its pretty obvious to see that they are both basic examples of a team. As simple as this sounds, in business the idea of a Cross-Functional team is complex and for some people unachievable and/or undesired.

Good Team Work = Good Results

When creating a simple product no one skill is above all others. It requires team work, collaboration and good communication. If you look at any product that inspires you, I am pretty confident it impresses you because the people behind the product worked well together. You only have to look at an iPhone to see that the designers, developers, engineers, marketing, sales and other areas of the business worked together to create a single product.
Creating cross-functional teams increase the potency of a product in the market place. Staying with the soccer analogy you can see the power of teams in almost every competition. If anyone remembers Greece won the UEFA Euro 2004, not by having the most expensive players, or the worlds best striker, but by having the mentality of a team and a desire to win as a team :
“The Greeks, dismissed as rank outsiders before the tournament with bookmakers giving odds of between 80–1 to 150–1 for them to win, defeated some of the favourites in the competition including defending champions France and hosts Portugal, who Greece beat in both the opening game of the tournament and the second in the final.” – http://en.wikipedia.org/wiki/Greece_national_football_team

Functional Units vs Cross-Functional Teams

One of the main arguments and a valid one which prevent cross-functional teams existing is the benefit of functional units. A functional unit is a group of people grouped by a similar function for example developers with developers, designers with designers etc. The benefits of which mean that as a professional unit, strengths and processes can develop well and they can communicate with strength and confidence on how to develop further. I have no doubt that grouping people by skill will have it’s advantages. The problem is that one skill doesn’t make a product.

The sweet spot of team structure is to have the teams arranged by a purpose (product), but to have the communication of functional units.To solve this problem you need to ensure communication is managed well and is very strong. That means that efforts have to be made in order for this to work. Again referring to the soccer analogy this happens quite nicely. Although you have goalkeepers and strikers in the same team, they don’t undertake exactly the same training all the time and come together at set times with purpose. Therefore strikers will train with strikers and develop the skills needed to be a striker, but play with all the other positions for the match.

In business it’s not easy to split people up like the training example above. People have computers, desks, commutes etc. Therefore how can this be achieved ? Well one thing we have tried in work with some success is to have scheduled “Round Table” meetings. These are set times where all developers, testers or designers from different projects meet and discuss their problems, achievements or proposals. This seems to have had a positive affect and are time boxed so they don’t interfere with production metrics. There are many other methods which could help achieve the above such as weekly, fortnightly meetings (limited time); where each team can tell other teams what it developed and what it plans to develop in and how (like a large scrum meeting), good documentation, set training etc. The point is communication processes and time need to be recognised and set up just as you would schedule training in a soccer team. Unless an effort is made to account for the problems with cross-functional structures, the negatives will be problematic and a successful team will not materialise.

Fielding A Cross-Functional Team

If I was a soccer coach and was dealt with the task of fielding a team for the next match how do you think the following tactic would prevail for 90 minutes :

Isolated Functional Units

Looking at the “Attacking Tactic”,I’m pretty confident although my team might score some goals, but the opposition would score more. Looking at the “Defensive Tactic”, I’m pretty confident that I can limit the amount of goals conceded, but my team probably won’t score many in the process. With both examples, I am also pretty confident the players, coach, directors and the fans would be a little concerned with my approach and probably question my capability as the teams manager. It’s pretty obvious the team in both examples is off balance and doesn’t contain structure, limiting the chances of success. However obvious in both these examples, businesses often adopt these structures. They have teams which consist of isolated skills and capabilities and then shut them off to the other skill sets, forcing them to work in isolation physically and discourage communication.

If I was however to field a team for match day which combined all the skill sets which had a balance between defence and attack, with everyone working with a common structure and goal, I would increase the teams chances of success. To put this in perspective, match day would be developing a product in the business sense. The following very simple example demonstrates a teams structure from a business point of view :

CFT Soccer Zones

Hopefully the example above clearly demonstrates why and where different skills are needed. (I know it’s very simplified).

If its that simple, why doesn’t everybody do it ?

The analogy in this post over-simplifies a sometimes very complex business structure. For instance football team is 11 players, where as a business can be thousands. That being said, the basic strategy is relative.

There are countless reasons why this doesn’t get implemented in many companies, some more valid than others. However in my opinion some of the most common reasons why this is difficult to implement include communication, responsibility, ignorance, confidence and trust. Let me explain :

Communication

Businesses are often structured by departments, not by products. Naturally the environment is restrictive which will reduce communication and if your are co-located or international you need to allocate time and buy tools to invest in communication strategies. Being structured this way also hiders incentive. Why should Sales communicate with QA for instance? They don’t need to, “we work over here, they work over there and we do different things”. Working in isolation reduces the visibility of the big picture which is that everyone is on the same team. Instead there is more loyalty and effort shown to the each of their own departments. Waterfall project models emphasise this in their structure, when phase 1 is finished move it to another department for phase 2 and so on. This approach is fine, but often as a project moves through the sections, the vision can be lost. In a lot of cases as the project moves on through the departments, the motivation, incentive and understanding can diminish as well, causing the business to be less responsive.

Responsibility

With skills/departments not communicating well with each other, responsibility and ownership sits comfortably within the departments. If engineering make a mistake, it’s not the responsibility of marketing right? When you group people by profession and isolate the skill sets coupled with poor communication of course, a blame culture is encouraged which furthers the separation between functional units. Unless there is a common responsibility between the functional units to communicate, they will drift further apart hindering the benefits of working as a team and therefore affect the product. Organisations who don’t encourage functional units to take responsibility help further the divide at their peril. However most organisations don’t identify, encourage or monitor this responsibility as such. Yes you do have project managers who work with many departments, however project managers can work with functional units in isolation which is no benefit in getting functional units working towards the big picture. In a soccer team, you have a captain, coach and manager all making sure the team is communicating, in business you don’t always have these people.

Ignorance

If your skills and interest are limited to your department, domain or comfort zone and you are doing what is asked, why bother helping or bother spending time working with others not related to your craft? Do people from IT really need to care what Marketing do or vice versa? Of course the answer is yes to the previous question. Ignorance is more than often a choice by an individual. It’s very easy to do other people’s jobs everyone will have you think. Breaking down the barrier of ignorance can have huge benefits not just for others, but also for yourself. If one understands how others work they might structure their work differently which could increase overall performance and efficiency. Taking the IT/Marketing differences as an example, for IT to receive a change request through from marketing to a preview environment it might benefit marketing to know that each chance to a static page of content takes 3 hours of testing and 2 hours of deployment for instance. Knowing this might ensure marketing provide copy in a better state before passing it to IT, which in affect could change 10+ hours into 5 hours making the company more efficient by saving time and money. I have no doubt that Ignorance like this is costing companies millions of pounds per day!

Confidence And Trust

Yes believe it or not this can play a big part in poor communication in business. Functional Units often have leaders. Some leaders like to lead and like to be seen leading. Where functional units isolate persons and teams away from the big picture which is the cross-functional team working towards the same goal, leaders with inflated ego’s will not want to communicate. If you think you are doing a great job you might not want to give other leaders from other departments any insight to how you work as it will expose your processes which may involve weaknesses as well as strengths. If a player a soccer pitch holds onto the ball all the time and doesn’t pass, you pull them onto the bench quickly even if they are very good individually. In business who does this and is it as easy to spot?

So Now What ?

Well this post explains a simple analogy of cross-functional team structures. Obviously businesses are complex, but the same approach can be applied. For cross-functional team structures to work, decisions need to come from the top and effort need to be made to encourage the structures/tactics to have a chance to work. Analysing operations and refining processes will go a long way on setting up cross-functional teams, but just like soccer teams, they need management, structure and direction. Unless the vision is shared, the functional units have motivation,ability to communicate and people see themselves as team members and not the team, it will be difficult if not impossible to implement. Creating cross-functional team structures is a culture change as much as it is a structural change. Such changes take time, effort and planning which deter most who don’t wish to undertake long term thinking. However implemented well just like Greece winning the European Championships, you can generate more output with less input and increase your chances of success. Not all companies can be structured like this, but I’m sure the one’s who do will not look back in most cases.

If you have any feedback on this post or your company structures and experiences, please send me your response.

Finally the long awaited iPad has has been released. For quite some time people had speculated what the device was going to be and what it would be capable of. This has been followed by some passionate underlying debates for what it should and needs to be for consumers. Well the device has been released, which has been met predictably by a mixed reception with continued debate. Following such debates, the key point of confusion standing out is people are unsure where an iPad fit’s into their lifestyle. This is the question I am trying answer from my own perspective and lifestyle, suggesting where an iPad would mainly suit me.

iPad doesn't replace PC's or smart phones

Being a Software Developer/IT Manager by profession I have pretty much access to a computer/device of some description most places I visit on a day to day basis. I currently use a ‘G1 Android phone’, have a ‘macbook’ for working on the move, iMac at home, and have a Vista machine at work, not to mention access to several remote linux servers holding my information. I also have an xbox360 which is linked to my media linked to the TV. With all these devices around me where would an iPad fit in and why would I want one?

To understand where an iPad would fit into my lifestyle, I have to look at my daily patterns and highlight where I waste time with a little ‘lean’ thinking. Pretty much most of the day I’m in front of a computer and I clearly don’t see and iPad as a suitable replacement/substitute for what I use these devices for. When relaxing in front of the TV, listening to music via the xbox360 and iMac, I don’t see and iPad offering anything against these devices. I certainly don’t want a 10 inch device to replace my mobile phone unless I was aiming to block out the sun. So what gap is leftwithin my daily lifestyle pattern?

Well looking at my daily patterns I quickly identified somewhere where I am wasting time which could be improved. As part of my day, I regular attend Scrum meetings, meetings with 3rd parties, and am often called for quick consultation from various parts of the business. Most of the time these can be quick meetings lasting no longer than 10-20 minutes. When called for any of these tasks, I find myself picking up my A4 notepad, rushing into a room and writing notes. Most of the time I then type up key points of the meeting on my PC. Sometimes however with interruptions I miss the odd one or two and end up being chased up by others where I have to then play catch up. For me, this is where I see an iPad fitting into my lifestyle.

If I could turn to the iPad rather than an A4 notepad this would mean I could take more information everywhere, makes notes once and most importantly of all for me is to free up my time. An iPad offers 10 hours of battery life and can stay on standby for a month! It is small, lightweight and quick to turn on and off which makes it a perfect fit to replace my A4 notepad replacement. I can make notes and pass it around the room with others to share information such as diagrams, images or notes, as easily as passing around sheets of paper. I have a macbook, but there is no way I could get it to fill this gap like an iPad could, otherwise believe me I would be already doing it. It’s overkill, less mobile, slower to turn on and involves launching full blown software packages. This is enough to say no and the A4 notepad has won every time. On the same note where I would use my macbook and smartphone, an iPad wouldn’t be a replacement for these. My macbook is good at being a macbook and provides me with the ability to have a mobile computer for developing code, running VM’s etc. My smartphone is too much of a compromise with such a small screen. Therefore I’m very glad Apple decided to make the iPad exactly what it is without a full OS trying to compete with the notebook/laptop devices. A purposeful and simple solution to fill an obvious gap in the market.

There are other obvious uses where the iPad would be a benefit and that is on the commute. I used to travel to work by train carrying at least one magazine, a book and a macbook every day. An iPad would have meant I could just carry a macbook with it, reducing the weight and giving me the ability to carry much more reading material. I don’t see the point spending on an ebook reader now when and iPad is just a bit more money for a lot more value in return. I could just pull out at any time to fill the short, but sometimes very long gaps between train journeys. If the train is 10-15 minutes late, I’m not going to boot up a macbook and find a place to sit on a very over crowded platform.

iPad replaces notebooks and ebook readers

Obviously my viewpoint above is selfish to my lifestyle. Who else could use an iPad ? Well looking at my circle of friends and family, unlike me most of them are not tech people. However, they all have computers and laptops and I know this as usually I’m contacted at some point if they run into problems. Looking at their use it tends to be mostly shopping online, social networking, emails and sharing photos. Most of them also seem to be intimidated and frustrated with their computers to various degrees. They look boring and a computer probably reminds them of the office they just left in the day. For these users an iPad could be a good option as it’s cheap ‘ish’, simple, secure and most of all friendly. It’s a device that can sit on the coffee table and be picked up and used anytime just like a magazine. For less tech savvy users this is far more inviting to use and therefore likely to get more use. This is why I’m glad they made it more like an iPhone than a notebook. It makes much more sense for this device to be app based and would be much more attractive to already proficient iPhone users.

I’m sure it won’t be long before we see Google responding with a slate device offering Android, not ChromeOS.

In the past few years I have read about Scrum, Agile and watched many a tutorials and short videos on the benefits and how to implement it in the work place. After watching from a far I managed to get my hands dirty and get involved with applying it in the workplace. Over a period of many months, bit by bit we have implemented it into our development environment. I have to say it hasn’t been easy and it’s only possible with support from the business in my opinion. Developers and testers were the first to welcome the change as it empowered them and gives them recognition for their efforts as well as control. The business took longer as the change is drastic and involves them a great deal more in product development. However once involved, the agility and development speed and project transparency becomes something recognisable and desired.

During this implementation a common emphasis raised via many sources is to keep the teams small and focussed. Many comparisons have gone through my mind, including why and how to select certain people and create teams. One of the best comparisons and inspirations to make sense of this is to compare the military structure. The comparison that strikes me is that traditional waterfall teams which consist of large scaled divisions that progress in linear fashions with a great deal of resources and structure. They take a great deal of planning, authorisation and strategy to get momentum. When the momentum has started, it’s difficult to stop and change direction. These can be compared to a military invasion, invading in stages as one large force following months of planning and financial investment all moving towards a strategic location in mass. Scrum teams to me represent a different dimension to this, I see scrum teams as small, more precise well equipped units similar to special forces. Smaller teams which are empowered, focused and take more control over their missions who often find themselves more capable and agile. They can be deployed into many different environments, are quicker to adapt and are in and out of missions quickly, sharply getting maximum results.

Over the past few years PHP has matured somewhat. Object support continues to grow and more demands for advanced web based applications/software have began putting PHP into a light of it’s own. The once simple scripting language has matured into a powerful OO web scripting arsenal which when combined with the right environments can run with the best of them. Those who push pass the beginners  boundary and delve beyond the simple tutorials and basic functionality, use the versatile properties of PHP with good design and OO knowledge who progress, achieve and develop great things and have fun in the process also.

With PHP being applied in new ways and object support it was only a matter of time before there would be an explosion of frameworks on the scene. Not least with such popularity and community support, the Frameworks that are out there are diverse and offer different development facets which can present developers and businesses many advantages in order to build complete professional solutions. With more and more enterprises demanding more from the web, frameworks are becoming more in demand and as such are snowballing in their release cycles to offer a toolkit that many developers and few workplaces can ignore. Many including myself having used frameworks find it difficult to develop without them due to the benefits on offer such as reduced development time and reusable code libraries

As a result of this PHP developers are presented with many frameworks to choose from, which can be a mine field. Although most frameworks are similar offering MVC based designs, some are quite different and vary in depths, versatility and complexity. These aspects should be considered by the developer when choosing the right framework for the job. I would personally recommend trying a few out to see what similarities there are, what suits your needs and what you feel you can mature with. I have tried CakePHP, Symfony and Zend Framework resulting in predominantly the later choice as I feel it suits my requirements as a developer better.

When choosing a framework in my opinion you should not only consider the current state of the framework, but also the support, community and demand for the frameworks you are considering from the business world. If your going to invest time learning, implementing and possibly contributing to a framework, knowing the demand from businesses should be an important factor as this could enhance your career prospects. This demand in turn can help secure a frameworks future as it influences support, training, functionality  through corporate recognition.

To help recognise which frameworks are in demand from the job market, I have called in a few graphs of the more popular frameworks to see the differences of demand side by side. I found it interesting and I hope you do to:

cakephp Job Trends

cakephp jobs

codeigniter Job Trends

codeigniter jobs

eZ Components Job Trends

eZ Components jobs

fusebox Job Trends

fusebox jobs

prado Job Trends

prado jobs

seagull Job Trends

seagull jobs

symfony Job Trends

symfony jobs

Zend Framework Job Trends

Zend Framework jobs

Obviously these graphs don’t represent quality in any way, but they should provide a general overview of demands by employment. This can indicate relevance as in most cases (Not All), demand should reflect some the benefits on offer from the framework.

I have been meaning to write a review on Woopra for some time, but wanted to try out Woopra for a while first to ensure I got more of an in depth experience whilst looking through the web statistics. It’s not easy for any stats package to get much attention with the likes of Google Analytics (which I currently use) to contend with, especially since most web statistics packages require the user to embed tracking code into sites which can impact page load times and is another stepping stone for integration. However I started to hear rumours there was a new kid in town by the name of Woopra and decided to give it a chance. I proceeded to set it up on this blog and another e-commerce site for a varied user base.

Live Statistics

One thing which stood out straight away using Woopra over other analytics packages was the ability to view live statistics from actual users on the site. I have to say I was a little pessimistic about this feature, having used similar features in the past. I was expecting, inaccurate details, delays and it being riddled with bot visits which would dilute the overall detail. To my surprise it was quite the opposite. I accessed the site from several locations using various devices, browsers and OS’s, then tracked my movements through the sites. Each time, it managed to detect my exact entry point to the site, the referrer I used (including the search engine search term) as well as my exact OS and browser. As soon as I started using this feature my mind was full of ideas where this feature could be a benefit to a website. My first reaction was that I could use Woopra to quickly identify bottlenecks in a system. By watching the flow of users through a site live, I could see any issues on a granular level. This could be very beneficial if you have changed a stage in a process, for example introduced or altered a stage in the checkout process. This feature will allow you to identify such areas quickly on a per user bases and could even be integrated with customer support to get more detail from the user allowing you to offer a better service at a time of need. You can offer a very proactive approach to usability and navigation by using such a feature.

Analytics Reporting

Looking through the quality of the statistics Woopra gathered through the live user tools as well as the historic analytic reports I was very impressed by the level of detail offered by Woopra. I did not see any evidence of bot contamination in my visit stats. I compared some of the analytical data Woopra had collected over a given time period with Google Analytics. I noticed that there were concerning differences in the details. To cross check both these I examined the actual access logs on the server to quickly identify which system was more accurate for example, by looking at the number of unique agents, visits and referrers. To my surprise the analytics seemed to favour Woopra in some cases although not all. There were areas of concern I noticed in Woopra particularly relating to the source by IP of the visitors. Although IP by Country seemed fine, I wasn’t confident that the IP to City locations were accurate and hence this affected some features which heavily integrated such data. Woopra had confirmed though the IP database being used in the beta program was being replaced and the current solution was temporary included due to financial constraints :

“We’re working up upgrading the IP address system. To save money, we went with an older, free version.” (twitter.com/woopra)

There were some differences where Google Analytics offered some data that Woopra doesn’t. However what I must say is where Woopra offered the same information as Google Analytics, I personally think Woopra presents the data in a more concise, detailed and purposeful manner. I started to find I had more interaction with the statistics offered on Woopra which allowed me to see some of the collected data in new ways. The level of detail shown particularly around referring domains and search terms in Woopra is excellent. You can instantly see a visual representation on a search phrase with the graphical detail helping you identify patterns and trends quickly. However there are areas which I didn’t test in much detail and that was based around PPC campaigns and such. It would be interesting to see what dedicated SEO specialists think of Woopra where PPC is heavily integrated into analytical campaigns.

Desktop Application & User Interaction

Analytics aside I was also very impressed with the desktop application to which I was using to retrieve statistics from my sites. The application is fast, well designed and offers a broad range of tools and filters which you can use to customise and extract data with. Since I have installed Woopra on my desktop I have actually found it to be quite addictive. It’s so accessible and easy to interact with I found myself constantly switching back and forth to find out more information.

Customer Feedback

As I have been testing Woopra out as part of the Beta program, I have been tweeting some of my finds on twitter. What impressed me was Woopra’s dedication to respond. I can confidently say that pretty much every tweet I mentioned, I had a direct response from @woopra with a constructive answer. This to me shows great product support and commitment by Woopra to make a strong product even stronger. This feedback and interaction process could really help Woopra get into a good market position quickly and I’m sure will also help the product develop into something the users really want.

Overall

To conclude this review, I was overall very impressed with Woopra. I would highly recommend anyone using or considering web statistic packages trying this out! The only issue I have left before fully committing to this package relates to the fact that this product is in beta and the final package price to my knowledge has not yet been released. Hopefully by spreading the word this could help reduce the price as I certainly want to carry on using Woopra. Watch this space, I think Woopra is going to be around for a good while!

Please feel free to add your comments to this post, I appreciate all feedback.

To find out more visit : http://www.woopra.com/

You can also follow Woopra on twitter at http://twitter.com/woopra

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:

1. The business has grown so fast, very little resources have been available to maintain the design.
2. 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.
3. 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.
4. 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
5. 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:

1. 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.
2. 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.
3. Easy to have multiple view types using the same business logic.
4. 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.
5. 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.
6. 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

Design Debt

MVC Defined

GUI Architectures

Big Ball of Mud