Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have very recently started a new project (MVC 3.0) and some of our early discussion has been around how the work and development will be split amongst the team members to ensure we get the least amount of overlap of work and so help make it a bit easier for each developer to get on and do their work. The project is expected to take about 6 months - 1 year (although not all developers are likely to be on and might filter off towards the end),

Our team is going to be small so this will help out a bit I believe. The team will essentially consist of:

  • 3 x developers (All different levels i.e. more senior, intermediate and junior)
  • 1 x project manager / product owner / tester
  • An external company responsbile for doing our design work

General project/development decisions so far have included:

  • Develop in an Agile way using SCRUM techniques (We are still very much learning this approach as a company)
  • Use MVVM archectecture
  • Use Ninject and DI where possible
  • Attempt to use as TDD as much as possible to drive development.
  • Keep our controllers as skinny as possible
  • Keep our views as simple as possible

During our discussions two approaches have been broached as too how to seperate the workload given our objectives outlined above.

OPTION 1: A framework seperation where each person is responsible for conceptual areas with overlap and discussion primarily in the integration areas. The integration areas would the responsibily of both developers as required.

View prototypes (**Graphic designer**)
         |
          - Mockups      
         |
Views (Razor and view helpers etc) & Javascript (**Developer 1**)
         |
          - View models (Integration point)
         |
Controllers and Application logic (**Developer 2**)
         |
          - Models (Integration point)
         |       
Domain model and persistence (**Developer 3**)

OPTION 2: A more task orientated approach where each person is responsible for the completion of the entire task (story) from view -> controller -> model.

QUESTION: For those who have worked in small teams developing MVC projects how have you managed the workload distribution in this situation. I can't imagine the junior would be responsible for building parts of the underlying architecture so would given them responsibility for the view make sense considering we are trying to keep it simple?

share|improve this question
    
This question is way too long for me to read and give a comprehensive answer to, but I will say I strongly suggest against designing and architecting a system based on the project model or process you're using or even the timeline (with exceptions for that last one). You're going to have to live with this design long after the project management or process has changed completely and after this specific project is over. Design it right for maintenance and extension, not for scrum or XP or any other immediate implementation process. That only lasts 2% of the software's lifetime. –  Jimmy Hoffa Nov 23 '12 at 21:31
    
@JimmyHoffa I could remove the PROS and CONS might make the question shorter perhaps? They were just my thoughts but potentially don't add to my real question anyway? –  dreza Nov 23 '12 at 21:40
    
I'm not certain what your real question is, maybe they do add Iduno, I'm just feeling too lazy to read the whole thing right now heh –  Jimmy Hoffa Nov 23 '12 at 21:44
add comment

2 Answers

up vote 1 down vote accepted

Option 2 seems much better for agile development. I really cannot see how option 1 can work with agile. So if you are favoring option 1, then I would have to ask if you are really doing agile.

The cons you mention are not really problems and if you think they are problems, then you should be fixing something else than "overlap" of developer work.

  1. If the intent of developer is not obvious from code, then this code definitely needs refactoring.
  2. There are tools to check and enforce coding conventions. ReSharper for example.
  3. what?
  4. This happens all the time, no matter where, how and who. You just need to make sure you have way to catch those problems soon(pair programming, code review, lots of testers) and be able to fix them efficiently(unit testing)

Actually, you could combine both options in some way. Take pair programming, give pair a feature to implement and then each person can work on different "layers". Of course this is not real pair programming. But you still get advantages of shared knowledge of said feature, better coverage of "what if", the pair can help each other and people can still somehow specialize.

share|improve this answer
    
Thanks. In this approach would one person have to take responsibility to review all code checkins to ensure any duplication of code is captured i.e. a method function already exists but someone re-writes it because they didn't look or know? –  dreza Nov 23 '12 at 21:17
    
Don't try to prevent such problems. No matter what you do, they will still be there. You should focus on fixing them when they show up. In this case, it will be best if people work on different parts of codebase and will have way to fix duplicates without need of complex process. –  Euphoric Nov 23 '12 at 21:22
add comment

Your question is fairly vague; I'm unaware of what your truly trying to ask.

Is it: "The best way to avoid overlap in our project" or "The best practice to get a lot of productivity with minimal overlap / benefits in our project?"

Assuming your asking about a pattern and practice; I might say... Service Oriented Architecture using Windows Communication Foundation. It will provide flexibility, extensibility, and abstraction if it is utilized correctly.

This can help each developer focus on a particular task; without overlap. So it can organize the task quite effectively.

A really nice example here.

You'll notice that it abstracts several aspects for re-usability. So an example with a Product and an Order.

Application Architecture


Assembly Separation

You'll have your:

  • Data Layer
  • Business Layer
  • Model
  • Contract
  • Service
  • Host
  • Proxy
  • Client

Which looks like quite a lot. However it really isn't if paired with efficient techniques. To explain the bulk of this approach-

Your Model will contain your object; this object will be capable of being exposed to your client. The Contract will provide the Interface your implementing; which can be broken down according to task. Then the overall Service; which will provide the method implementation.

By the approach taken; it will allow you to host the project through Internet Information System, Windows Activation Service, and communicate over a vast array of technologies with an assortment of security as well.

The benefit of this approach will even implement some techniques you mentioned. As your inheriting the functionality of each method; into the Client Proxy. Which makes the re-useability quite nice and the implementation quite clean / easy.

Anyways, that is my two cents. How it will fit into your project- I don't know. As Martin Fowler stated: "Frodo said in Lord of the Rings, Go not to the Elves for counsel, for they will say both no and yes." Which makes perfect sense, advice can be a dangerous gift especially with a brief description. We don't know your project, goals, or particular growth details. Which can make any design or pattern a nightmare; especially since our recommendation may sound solid but in reality do your project a great disservice.

Ultimately your knowledge of the project and suggestions made can hopefully point you to the proper choice.

The article in that link will really go into detail and explain what I mean about the pairing and usage.

share|improve this answer
    
Cheers Greg. It's not about the design of the application but more of your first option on how to structure the workload between the developers for least overlap and the best way of working etc –  dreza Jan 4 '13 at 0:47
    
Hopefully my approach can help clarify then. As it not only provides flexibility; it also provides easy management. Especially since it allows a nice solid Domain Model / Data Transfer Object / Remote Facade techniques to make it fairly robust. Plus you can break each task into it's own individual service so each developer always knows which task they are accomplishing. –  Greg Jan 4 '13 at 0:56
    
I'll read your question but it seems to be for WCF which is not what I was asking about. Might be relevant, I'll have a longer think. Cheers. –  dreza Jan 4 '13 at 1:00
    
Windows Communication Foundation can fit into your current project; WCF is simply a transport. It provides local or web based services. So it can be consumed through several means, including Model View Controller Projects. It is simply the communication outward. It is quite powerful. Hope that helps. –  Greg Jan 4 '13 at 17:19
    
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data. –  Greg Jan 4 '13 at 17:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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