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.

What practices do you apply when working with large teams on multiple versions of a software or multiple competing projects? What are best practices that can be used to still get the right things done first?

Is there information available how big IT companies do development and management of some of their large projects, e.g. things like Oracle Database, WebSphere Application Server, Microsoft Windows, ....?

share|improve this question

closed as too broad by user61852, GlenH7, BЈовић, MichaelT, World Engineer Jun 29 '13 at 1:02

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
you have multiple questions in one here, and they are quite vague. –  lwm Sep 10 '12 at 9:15
1  
so how do i ask such a question here without getting downrated? –  centic Sep 10 '12 at 13:14
    
This downvoting is discouraging. Why so many down-voted questions? Your question is in my opinion right on mark for programmers interested in large (10+ people) development projects. –  Edmon Sep 10 '12 at 14:41
3  
I would say its very vague. What are the "right things". What is a "large team". What methodologies are currently in use? What is the current problem with how things currently are working? –  Rig Sep 10 '12 at 15:27
    
@centic, have you read through a lot of questions here and the FAQ to understand some of the basics here? That would be my initial question. –  JB King Sep 10 '12 at 19:48
show 2 more comments

3 Answers 3

up vote 2 down vote accepted

You're basically asking "what's the best way to write commercial software", and if you ask 5 guys you'll get 8 answers.

Therefore, the best answer I can give to such a broad question (not sure it's "overly broad" and thus a candidate for closure, and thus I will try to answer) is:

IT DEPENDS.

It depends on how many developers are working together. In a smaller development environment, say in a medium-sized business that insources a lot of custom app development, there may be a lot of projects that need to get done and very few programmers to do them. In that case the IT manager usually hands each project to one, maybe two developers and say "get this done, do as good a job as you can but I need it in a month". This is usually a pretty free-flowing environment in which self-starting "lone wolf" programmers can thrive. However, in such an environment there tends to be a lot of competing frameworks brought in independently of each other by developers who don't sit down and talk about unified structure. Code quality can suffer, and code often doesn't adhere to any one "manual of style" other than maybe what's defaulted by the IDE.

On the other hand, code houses generally organize into teams, throwing as many people as the schedule and budget for the project call for. These teams require not only self-starters, but good team players who communicate with each other and collaborate. This provides the "synergy" that managers love to talk about, increasing velocity. But, that requires the entire team to be humming along like a well-oiled machine, and to have a project manager that is good at keeping the development roadmap free of obstacles.

It depends on how many projects need to be developed concurrently. Generally it's a good idea to keep one team working on one thing until they're done, then reevaluate the team's size and makeup before assigning the next big thing. Keeping a team doing one thing keeps them focused. However, the more people per team, the fewer teams you have, all other things being equal. That increases the velocity of the team on one thing but may decrease overall throughput. Incorporating work items from other projects into the schedule for a team gets the small things done but takes the focus off the main project, causing a reduction in velocity caused by mental gear-shifting. Small teams reduce velocity but increase the number of concurrent "pipelines", reducing time that items sit in the backlog with other department heads going "why haven't you started work on my project?".

It depends on the scope and budget of projects. If a client needs one developer to augment a site that their in-house UX guy has wireframed, and they need it in a month for $10 grand, and all those constraints are feasible, there's no point in assigning an entire dev team to it; it's not what the client ask for, what they need, nor what they are willing to pay for. Conversely, having a one-dev team work on the next in-house superproject is not a really good idea if you can help it; not only will development be slowed because only one guy's coding it, you're only getting one developer's perspective on the solution which is by its nature going to be a limited one.

share|improve this answer
add comment

Creating big software is a hard thing to do properly, and folowing good practices is very important.

A good start is to design the system properly. Partition it as much as possible, and create good interfaces (that's why hardware engineers are some times very good architects).

Common concepts apply there as well (code repository, unit testing the code, contious integration, etc).

share|improve this answer
1  
+1 for System Design - it is amazing how often software people just dive in and start coding. –  Andrew Sep 10 '12 at 9:10
    
@Andrew Well, that works well for a prototype, if you are going to throw it away. –  BЈовић Sep 10 '12 at 11:23
    
but how often does prototype get thrown away at the end? More often than not, you spend twice as long (at least) production-izing it... –  Andrew Sep 10 '12 at 11:44
    
@Andrew That is why people usually create prototypes in different language :) –  BЈовић Sep 10 '12 at 11:49
add comment

It depends, but there are few aspects which are common in all sorts of programs.

  1. Start the development from the systems point of view - Memory Management, Process Management, etc.

  2. Perform efficient coding. Do not put in all the code in a single file. Make various function and call them, that's a good practice.

  3. Try to shorten your code as much as possible and deploy as minimum number of variables as possible.

  4. Focus more on saving system memory than saving drive space(although both are equally important). System memory has to be handled with care so that there isn't excess utilization than what the customer expects it to utilize. Nowadays we have hard drives with massive space so disc drive space won't be a problem, but again the efficiently you code, the better is disc managment.

You won't be told to do everything on your own, so focus more on your duty than worrying about the final outcome. Its a wonderful experience. And make sure you enjoy doing it :-)

All the Best.

share|improve this answer
add comment

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