My colleague Jon George has recently been posting about his experiences of performance tuning our latest web application, built on Asp.Net MVC. His introductory post talks briefly about how we spent a large effort in laying the correct foundations for the project, which have ultimately led to its success. Being the “technical lead who had inconsiderately booked his wedding and an extended honeymoon right in the middle of the project”, I was obviously keen to ensure that that project didn’t fall down in a big heap whilst I was away. Although Jon would have you believe otherwise, my wedding and subsequent absence was actually planned well before we embarked on this project, so I knew from the offset that we had a risk around handover and consistency of delivery during project’s lifetime. To add to this, this was my first “official” Dev Lead role for EMC Consulting so I wanted to make sure that we got things right from the offset.
Howard and I started planning and brainstorming how we were going to approach this project well before sprint zero. We were lucky to have few technical restrictions, but the side effect of this was that we had a vast amount of decisions to make, with a vast number of options for each choice. We decided right from the offset that we were going to use Asp.Net MVC. We both have a background in web development, before .Net and Webforms, so moving back to a more “webby” web framework was something that we were really keen to do. We’d also hit a lot of pain-points in previous projects with Webforms and we were hoping MVC would allow us to get round these and do things the way we wanted to. MVC Version 1.0 had literally just been released, so we were good to go.
One of the main benefits mentioned when discussing Asp.Net MVC is the use of convention over configuration – a design principle that aims to reduce the number of decisions that developers need to make. The result of this is consistency, less code and an overall decrease in development time.
For example, in the MVC framework all controller classes are named with the suffix “controller”. So, if you have a controller responsible for search functionality, you know you need a SearchController.
Removing a decision needed to be made by a developer (in this case, what to call a controller class), albeit on a minute scale, adds up when when you apply it time and time again over lots of different conventions throughout the lifetime of a project. Asp.Net MVC does not enforce these conventions by any means, and practically everything is overridable, customisable or configurable – but each time you break from a convention, you’re adding time, complexity and inconsistency to your project solution. In short, if you follow the conventions, things are quick, easy and consistent. Happy days.
A lot of the communities around Asp.Net MVC have adopted this love of conventions too. We built our site around Billy McCafferty’s excellent Sharp Architecture, which is a “architectural reference for a best practice Asp.Net MVC web application” i.e. it defined the conventions on what we needed in an MVC solution, were everything would live and how it would all talk to each other. This, in turn is built upon James Gregory’s Fluent NHibernate – a project solely concerned with defining a convention based approach to using NHibernate, in order to eliminate the need for manually editing XML mapping files. Like I say, conventions at a minute scale all add up to save time, remove decisions and increase consistency within a solution.
The suprising thing was however, over the course of the project, this convention based approach extended out of the MVC solution and started to permeate other parts of the project and the team. We’d set a firm foundation of how we were going to build the code, but we had also been setting firm foundations of how the project was going to run.
As Jon mentioned, I’m a big fan of Getting Real and set out from the beginning with it’s principles in mind. We had a fixed budget and a fixed delivery date, so the scope of what we were delivering had to be the thing that moved. We were really cutthroat in determining what was “core” functionality for our site to launch. This was drilled into everyone who got involved with the team over the course of the project in order to eliminate scope creep from all angles. “We are only building core functionality” became my mantra and resulted in a convention that everyone understood, which was to say no to any new feature requests. If the client pushed, then they were added to the end of the backlog, well away from the core items that were to be developed first.
We were told to “spend the money as if it were our own”. We adopted this mantra right from sprint zero, evaluating and spiking a multitude of open source technology which we baked into our solution from the beginning. This convention of challenging every cost enabled us to validate and prioritise our requirements. “What's the added business value?” is a question that would be asked a lot if the team thought we were being asked to develop something they thought was giving little benefit. Being able to challenge functionality allowed us to really concentrate on our core features – which ultimately lead to us delivering the project ahead of schedule.
I set a rule in the first sprint that every team member would demo to the client at the end of every sprint. Whilst sprint demos are not a new thing to most people here, not everyone always gets the chance to demo their work, for various reasons – team size, time constraints, client involvement etc. I wanted to instil a convention right from the beginning that everyone in the team would demo what they had done during the sprint. So, we had designers demoing new creative work, developers demoing functionality, testers talking about bug counts, cross browser issues and running automated UI tests, database developers demoing BI and ETL processes. Whilst not all of this interests everybody, there was never any question of whether someone would be required to “show and tell” what they’d been up to. The result of this was that we never wasted time during a sprint discussing who would demo what and everyone made damn sure that what they were doing worked by the end of the sprint.
The combined effect of all these conventions is that everyone on our core project team is able to explain “this is how we do things on this project and these are the reasons why”. That’s a powerful message. One of the main benefits of working in a consultancy is that we have experts in a long list of specialities and whilst those skills are not needed full time for a project, its great to be able to draw on that experience as and when required. We had a core team of less than 15 people, yet over the lifetime of the project, over 30 of our consultants had provided direct input into the end result. Without embedding, understanding and enforcing our project’s conventions within the core team, this could have been messy business.
So, what’s the point in all this? Well, as Jon stated, I “abandoned” the project right in the middle to take a 6 week honeymoon. (pause for memories of sun, sand and… well, you get the idea). I was confident when I left that the project was in safe hands – we already had a great team and Jon is a great Dev Lead himself. But I don’t think I realised just how well everything was going to go. We had a brief handover where we discussed loosely how I thought features were going to pan out and left it at that. I returned after 6 weeks to find that
- The project kept momentum and had considerably moved forward in terms of functionality
- The features we had discussed had been developed in the way that we talked about - with no issues
- Jon had quickly engaged and developed a relationship with the client as he understood the solution and how we were running the project
- Everyone had been demoing their feature-complete work at the end of every sprint
- No new features had been added to the backlog
- I was able to easily pick up the solution where I left off and continue to work on the new features that had been developed
- The client was still happy!
The project didn’t fall down in a big heap whilst I was away, in fact it carried on at the same pace, quality and direction that it had before I left. That could actually say something about me! Or probably more about Jon! But I think most of all it says that if you spend time getting your conventions right then a lot of things will just fall into place. And that makes for a smooth running project.