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.
Separation of Tasks in an n-tier app: By module or by tier?
programming practices
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.