Dahlia Bock

6Aug/092

Why I think layer teams are a bad idea

So what exactly do I mean by 'layer teams'? I mean structuring your software development team in such a way that you have a group of developers for each layer (or more), e.g. UI, services, database, etc. So a UI developer is only concerned about one specific part of the application, namely the UI, obviously, and the Services developer with the services, and so on and so forth.

Problems that I've seen surfacing from such a setup:

  1. There's an enormous amount of overhead time spent going back and forth between the different groups when defining interfaces. Maybe it's the nature of the teams I've worked with in the past but IMHO this extra time could be spent writing tests that iron out the interactions between the layers.
  2. Then there's another chunk of time spent putting those pieces together and making sure they work correctly, i.e. integration.
  3. This causes silos in the development team where only some people know about the UI, others about the back-end services, etc. This discourages developers to step outside their comfort zone to learn another person's 'trade'.
  4. Update >>> Introducing specialized teams also increases the amount of distrust between the teams. One example is the database management team holding on to the schema and data for dear life and believing that no developer should have access to change it. Maybe this is common situation across a lot of projects regardless of team setup, but separating the team does decrease their level of trust for each other.

What I think is better is to have every developer comfortable with every part of the application, even if it means taking a productivity hit - as I've heard it being said. Let's say I have a story on the wall that says: "Add item to shopping cart". Ideally, a pair of developers would start first by working with the QA to define acceptance criteria and writing the acceptance tests for that feature. (This is a side note to a session at Agile 2009 that I'm very interested in: Where Does Developer Testing End and Tester Testing Begin?. I wish I was able to go.) Then they would implement what is needed to be able to click through on the application to add an item to the shopping cart which eventually ends up in the database.

20Feb/090

Integrate integrate integrate

My first project at ThoughtWorks was with a big medical systems provider. We had a big team of about 50 consultants distributed amongst multiple work streams. Each work stream had their own build and needless to say, it was an integration nightmare. There were about 2 or 3 levels of integration builds and they each had a long feedback cycle and of course, was quite brittle and prone to breakage.

Although those broken integration builds were painful, but I am now thankful that they had them at all in the first place.

Phil and I were recently astounded by the fact that we were getting a null pointer exception in the front-end application and we were frantically trying to figure out what we changed in the last 2 hours that could've caused such a problem when we realized that someone had changed some php code in one of the back-end applications and since there were no integration tests or points at all, it took us forever to figure out what was going on. Best part was, the apps were released to a dev-integration environment en route to production with this bug in it and no one knew until we spoke up!

I do wonder how it is possible for anyone to build 2 or more applications that are designed to talk to each other but don't provide a channel by which they can. Integration points are painful, but the earlier you do it, the better. Gotta remember that...