Thursday, April 09, 2009

Dividing application work horizontally rather than vertically

My colleague and I took a trip to the Microsoft SDC in Sydney the other week as part of an 'open day', where MS staff and partners described their development and project management methodology - basically a flavour of Scrum. Although a lot of what they are doing is very similar to our own process (which is a good sign I guess) there were a few things I thought worth considering. One of these was horizontal allocation of tasks amongst developers

Basically they advocated splitting the development of functions / user stories into tasks to be divided amongst several developers according to the tiers in the architecture. Whereas we (and many others) normally assign a single function/story to a single developer to code the entire stack (DA, BO, UI) they would assign this work to three developers. The argument they put forward for this was skill specialisation - a data access developer has a different set of expertise than a user interface developer.

Whilst I agree with this to some extent, no developer I know would be happy to be stuck working in a single tier of the app for the entire project.

However thinking about this more, if we did enforce the standard that the tiers of a single story must be developed by different developers what would be the outcome:
1. Developers would have to talk more about the design before coding
2. No single developer would come up with the design
3. Separation of responsibilities of each tier in the app would be easier to enforce (you'd need at least two developers to collude to change the design). Coupling between tiers would hopefully be minimised.
4. Each developer would know about more parts of the application.
5. More stories would be completed within an iteration (rather than having multiple stories still being worked on by individual developers at the end of the iteration, we'd have one or two being worked on at the end)
6. If developers worked on different 'tiers' for different stories there would also be more consistency in terms of coding style - patterns, naming, layout, etc
7. Higher chance of code re-use since developers would know about more areas of the application.
All of these are positive effects, completely inline with the tenets of agile - collective code ownership, collaborative design, pair programming (sort of). I can't really see any downside to this except a co-ordination issue (we need _something_ for project managers to do!), though the proof will be in the doing..

Now I'm off to find a suitable project and some developer guinea pigs...

1 comment:

Unknown said...

It works well, if you can find the people who enjoy living in a single tier. Some people love working in the frontend (eg. me). Some people don't know the difference between a H1 and a styled heading and just want to write hardcore integration code.

In past jobs I was working on a large self-help web app for BigPond. I was in control of the frontend group and another team looked after the web service / dao layer. If we had the people we would have had a third team work at the database level.

It works well only when there are clear interface definitions (eg. documented APIs, even on a wiki) and more importantly ownership of the API. The frontend team only needs concern themselves with the interacting with the user and getting/setting the data they need via well defined APIs. Other teams only care about writing reusable services that are easily testable.

Anyway, I'm happy to be a guinea pig in the next suitable project to give it a try!