Separation of Tasks in an n-tier app: By module or by tier?

Question

Developing an n-tier app with a team, is it better to divide tasks by module or use case (e.g. Employee 1 creates Admin module, employee 2 creates Payroll module, etc.) or by tier (e.g. Employee 1 creates UI, Employee 2 creates Logic, Employee 3 creates all Data Access)?

I'm more inclined towards the former. I think that it's only logical that if I'm coding one whole module or at least related use cases, I would be able to code continuously without waiting for others to finish before integrating my work.

But the counter-argument, which is the latter, is that by separating tasks between layers, a programmer can take advantage of n-tier's separation of concerns and focus only on a specific layer (to some) they're familiar with.

Answer 1

Don't use the tiered approach. It's a one-way ticket to integration hell. Also realize that you will not be able to release anything at all until all layers are complete, which usually means at the end of the project (if at all).

Better approach: focus on features. That is what our customers are paying us for. Create each feature and make it complete, from top to bottom. Grow the architecture/tiers feature by feature, using refactoring to keep it in good shape.

This approach makes it possible to release (or sell) the system each time a new feature is completed. This is great since you get actual user feedback earlier and can adjust the project based on that. I'll bet your customer will be more satisfied as well.

Answer 2

I think there is a third option: Create each layer independantly, and stub out the layer below until you hit the bottom. This way everyone can work on all the layers, one layer at a time.

This also prevents over-specialization, where you are depend on one person doing a specific part of the application, and that nobody else can reasonably fill their role in time if you suddenly lost that developer.

Also, this gets the UI done and hopefully signed off early on. Which, really is all that matters to a client. This way they can "see" functionality, even if it doesn't really exist yet, which makes it easier for you to change.

Answer 3

I think that you can make 2 analysis:

1. Technologie focus: if each part of the team handles well a certain technologie, the i would use the tier division (generally each tear has a more or less a set of technologies associated). This way you can use your UI's specialist to take care of UIs, and so on.

2. Objective focus: if you have a more homogeneous group ( everyone has the same knowledge in the technologies involved) then is more complicated to optimized the work/person relation. Then i would say the module approach is better.

Anyway, this are not the only options but it would be my approach on the matter. Hope this helps!