Two approaches of task distribution in a multi tier application

Question

I am working on a large web application in Java using Spring and Hibernate as the persistence solution. And as for the methodology, we're on Scrum. My role is that of a Scrum Master. I am also the one managing the business requirements and overall direction of the application.

While dividing the requested features into tasks, we have two conflicting point of views. I'd want you to evaluate both ways and let me know your experience how you all are doing out there.

First approach

Divide the task into layers of it i.e. the POJO, the DAO, Service layer, Controller, and the View (JSP, JSTL, EL, JavaScript). Now each person works ONLY a single layer. For instance, the POJO guy is the one who will always develop the POJOs of each of the features required right from the User management to inventory, accounts and all.

Similarly, DAO guy would always expose the methods for DAO and would do nothing else. Same for the service. Then are the guys on the controllers only. They do nothing just write the controllers. And then are the one working on the view. The do nothing but writing the JSP for the controllers, the JavaScript interaction stuff.

Upside

• Each one is restricted to a particular kind of skill and area.

Downside

• Lots of communication overhead. POJO guy tells DAO one, and that one to the layer above it.
• Might not yield coherent design.
• Your team member's skill set would be jagged, can never work independently if restricted this way.

Second approach

You divide the requested feature and distribute them based on funtionality instead of the logical layers they lie in. For instance, if its about the User management, its a single developer responsible for desigining the POJO, then exposing the DAO for it, writing service layer on top of it, then exposing it via controller and rendering its views (Of course not the asthetic design issues).

Up side

• The features designed would be coherent.
• One developer is building the whole "column" required to implement a particular feature.
• Also, developers would get the understanding of the all of the skills required to roll an enterprise application.

Downside

• Only criticism has been that it requires more in depth understanding of the framework.

I'd like all of you express your ideas on this and how you're doing it in practice.

Answer 1

We recently did our first large Spring MVC project, and we did a little of both, but ended up with the second approach. When we started we distributed the components based on initial skills: the database guy did the DAOs, etc. But as we went we made a point of trading around. That way, later non-DAO experts could use the early DAOs as references, and vice versa for JSPs or controllers.

As it ended up I'm glad we did it this way, since I am now responsible for maintaining the project -- it's a good thing I've worked on every layer.

Answer 2

More Upsides to the first approach

• People can focus on lesser number of areas at a time and get a deeper understanding of each matter they're dealing with - great for self confidence. Depending of size and skills of the members, you might end up having single person responsible for multiple layers.
• "Overhead of communication" actually shares knowledge about a feature, so it's likely that more people will understand a feature, and probably understand overlapping areas of code from someone else's area. This fits great in ideas of pair programming and collective code ownership.

In the long run, team members with greater capacity will eventually get to work on every layer. On the other hand, it is essential that a beginner is not made to work on all layers at the same time.