Project PitBull - Design & Planning

This is the first in a series of blog posts about a new project I'm working on. Project pitbull is a codename I made up for the project and this first blog post is design and planning.
The good news is we get to use the best technologies and its primarily Fluid eng development frontend and backend. The bad new is the date is very aggressive and the launch date is already set...as well as scope :-(

I'm working with another great dev at Fluid, Ward, and we both agreed that we're going approach this work the way we think it should be approached. We are purposely not diving into code (despite schedule pressures and the need to show progress) but will first:

• study & understand the requirements and problem domain. One of the most common causes of failure is related to requirements. To understand requirements do walkthroughs, ask questions, consider what if scenarios, draw diagrams and validate them (even if just on paper).
• create designs, UML class and sequence diagrams mainly. This is critical for the team to come up with a solution as well as so that the team have a shared vision of what the solution is. We'll be working on same code, we have to be on the same page as to what the design is.Test the designs with scenarios.
• base tasks and estimates off the designs. How often do teams really get to do this?
• base sprints off tasks and estimates

Design
As developers we must resist the urge to rush in and start coding. First, think about the requirements and problem domain, then come up with designs. One reason I say this is because once you start coding its hard for most developers (well at least me!) to step back out of the details, in addition once you have coded something it takes on a life of its own, it can become much more difficult to change it or replace it...it becomes your "baby".

Design phase does not have to be an onerous task either, in approx 3 days effort we completed a first pass for the design.

Some MVC "rules of the road" we're following:

• in MVC, as Ward said so well, "someone has to be in charge and its best to make it the model". That means when something needs to happen then it should be driven through the model. Listeners (such as controllers) listen to model changes and then react to those model changes and do things such as update the view. This must be the cornerstone of your designs and code.
• keep your controllers light and models heavier (i.e. prefer to put business logic in the model)
• typically there's a 1:1 model, view and controller relationship
• we ended up with more view and model classes than I expected, but that's whats really required. Do not be afraid to decompose as the problem space requires. Its easy to collapse a good design later then it is to expand a bad design.

To borrow a phrase from '94: "Its the model stupid"


This is the draft of the design I was considering. Since its a Wizard style app and states are involved I was thinking of using the GoF State pattern for steps. Plus choices holder as well as a possible choices as model data.

Ward had a design from a previous project similar to this which we though might be a good fit but then realized that only parts were applicable. The Facet part was an exact match to our domain and the concept is carried through in the new design, alibet with a different name and structure.

Mashing these designs up we evolved the final design through the course of a number of discussions and whiteboarding sessions.

We then ran scenarios against the design such as navigation including back button, complicated steps and validation with backend api developer for api approach.

The design is documented using a UML drawing tool.

Is design all nailed down? No.
It is correct? As much as we can tell but for sure we can expect there will be some changes.
What we can say is we think enough of the design is in place that we can move forward with it.

Planning

• We created a Google doc spreadsheet for estimates. It has columns for view styling, view markup, controller and model coding work as well as a bucket for other work. So for a particular MVC we estimate each of those. The PM will take that and put into plans.
• Thankfully we do have almost completed Visual Designs as well as Wireframes so we can be pretty accurate in estimate work such as view styling.
• Our sprints range in duration from 4 days to 8 but typically we try to keep to a weeks work and group logically similar work. 
• We realized that the client side code falls into 2 main sets of functionality, the Wizard and everything else) so we plan to develop in parallel.
• Estimating took approx 2 days and I think more time is required. Most importantly we had designs we were estimating against. Next we will work with the PM to explain so they can create Gantt chart of parallel sprints and level resources.
• Update: we're using Redmine to track sprints and tasks. Its not bad. I originally planned to use Trello which I've used before and liked but am fine with changing and Redmine is working out well.

Thats it for now. Next we need to do setup and get initial app skeleton coded.