Storming Through the Design!

 (Model Storming)

Some notes on approaches I have found successful whilst working with distributed development teams

I work as a Senior Technical Architect (Consultant) @ Astadia.com, my role is to architect cloud based solutions for large blue chip clients and manage the build phase of the project from a technical perspective.
I work with distributed teams of Architects and Developers in multiple time zones, and the following post describes some techniques that work well for me and the team.

Typically the quicker we can demonstrate features/functionality to the business, the higher the quality of the end deliverable will be.

Following the Requirements Capture stage (typically in the form of User Stories), I take the following approach to kick off the Design:

I create an initial Model/Design to Support the requirement in question, this is typically done using standard modelling approaches such as Screen Mocks (Balsamiq), UML Artifacts (Sequence Diagrams for complex logic etc). This initial design is created before I collaborate with the team on the finer detail of the design and I always ensure the User Story is visible at the top of the design document for easy reference.

When I believe the High Level design contains enough content to convey the design concepts, I will set up a Model Storm session with those on the team responsible for taking the design and implementing it.
The Team will participate in these Model Storming sessions over Voice and Web from distributed locations.
These Model Storming sessions typically last around 30-45 minutes, and are iterative depending on the complexity of the solution being proposed. Simple solutions may only require a single Model Storm session, but more complex designs, will typically have multiple Model Storming sessions throughout the build phase as the design is refined.

The 'Glue' that allows me to collaborate with the team effectively, is primarily Google Docs.
I find this tool invaluable whilst working on a design with the team. It is effectively our team whiteboard!
It allows other members of the team to add questions to the initial design in real time at relevant points in the document, and these are then addressed as we progress the call. e.g.:

• Dev1: Should the Submit button provide validation before posting back to the server?
• TA1: Email Address and Tel. No. should be validated client side with a message back to the user if validation fails and an indicator on the fields that have failed validation.

These collaborative comments are added to the design artifact as we talk on the call, any concerns are raised immediately and visible to all participants and if a solution to the question is known this is also added in real time.

This design artifact becomes a living document through the build phase, and includes an audit of design decisions made. 

I find this approach produces a really focused design for the User Story in question and ends up being a more  accurate reflection of the actual Design/Implementation as it is frequently updated/living during the build phase.

It encourages collaboration, everyone on the team has a voice. It allows us to get a working solution in front of the business as soon as possible as it reduces any misunderstandings and therefore reduces re-work time.

It certainly has improved the quality and speed with which we can react to the Business!

More can be read around Model Storming at Scott Amblers site - Agile Model Driven Development

Invest now for a brighter future!

How does the title - "Invest now for a brighter future" apply to software development?

I've worked on quite a few engagements where the original solution is often extended/enhanced many months after the initial build/release phase is over and typically by a different team.

When building software, there are some simple things you can do in the 'now' that will assist with quality further downstream. 

Often yourself, or the original development team may have moved on to pastures new and the maintenance of the original solution is left to others. 

The new team may have an understanding of a module within the solution, but often this is based on their assumptions and is often not as complete as the understanding the original team had whilst developing the solution - even with comprehensive documentation!

What can I do in the 'now' .... 

I've built a web page that displays widgets. It's clear during the initial development what the navigation paths to this new page will be, but what happens downstream when the customer would like to leverage this asset from another entry point within the application? 

As a new resource on the project, I could call the page and assume I have passed all the parameters required to render the page correctly, but there may be some exceptional use cases for this page that require additional parameters to be passed in for it to render correctly or for extended functionality to operate correctly.

I would say at the initial point of development, I am best placed to know what the mandatory parameters are, and as such I can invest some effort in ensuring that anyone calling the page has passed in the expected values. 

I could throw an informative exception if a parameter is omitted from the URL. This would ensure the issue is resolved early in the development phase and can be addressed upfront. (Early = Cheaper/Easier to resolve!)

This approach to protecting public interfaces from calling code is often referred to as Programming by Contract or Design by Contract and is still a useful tool in the toolbox for software developers wishing to ensure quality when changes are applied in the future.

So consider investing now for a brighter future - or at least, a brighter future for the solution!

Make the asset you are developing, an asset to your development skills!

http://en.wikipedia.org/wiki/Design_by_contract