About a year ago at my workplace we decided to get into developing a web app for internal use (as part of a more intricate system which is irrelevant to this question). No one really had experience in web development, so probably some of our decisions were wrong, but all in all we've had success with the tool we were developing. Since we did have experience developing in Python, we chose Django as our platform.

My question is about "who does what". The way we split our work was: there is one team which handles all the Python code - which means all the Django urls, views and models, as well as the actual backend to handle asynchronous task execution (something a bit like Celery). A different team (more precisely, a single person in a different development group - but this is just implementation) is responsible for the templates (data binding), javascript, design, HTML, CSS, etc.

We have been working like this, as I said, for about a year now. I'm starting to think that maybe the line of responsibilities between the two teams is wrong. The reason is that there's a pretty big overhead whenever we need to interact - which is a lot. For example, when we add a new table and we want to display it, we need to let the "frontend guy" know what the url would be and what it would contain. Then we need to integrate out work to see if everything's alright. Sometimes we didn't pass enough context to the template to make it work and there's a slow ping-pong of information between us.

So my question is this - what is the accustomed way to split work on web apps? Who takes care of the different modules - models, views, urls, templates, design, user experience, HTML, CSS, javascript?

3 Answers 3


In small teams you need some cross over of skills, otherwise you're spending a lot of time communicating ideas between devs who may have differing understandings of how those ideas might be implemented (as you have found). Better to make each dev responsible for a single feature, including front end and back end. Communication on ideas then only needs to be at the conceptual level.

Of course not all devs have their strengths and weaknesses, and I've not found that expecting the same performance on all tasks from all devs is practical. Assign features based on skill set. If the feature is more front end than back, give it to the front end guy, and vice versa.

As projects get bigger, then you'll see more specialization in developers. In this scenario, the communicative effort is not such a problem as the feature is profitable / valuable enough to make spending the time worth while.


I don't think a strong split like this is necessary. Pretty much all devs I've been working with were capable of coding backend and front end. We did have a go-to css/html guy, though, who could make the markup look good, so we could throw in a rough styling, code around it, and push it over to him to polish. Sometimes we also had people who would create design mock-ups and think about the UI flow.


My preference is to work on "features" rather than tiers of an application, whether it be a website or otherwise.

Any kind of "tiering" be it in an application or some other boundary (physical geography, groups in a company) is a barrier to development.

Communication needs are increased, and there are more potential blockers.

  • This is what we do. Everyone works on their own set of features.You can still put people on specific features depending on their expertise. For instance, I usually write the imports and exports with 3rd party systems, and my coworker does finishing touches on everyone's views, so the application doesn't look like it was designed by programmers.
    – Abuh
    Jan 23, 2014 at 8:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.