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, ....?

  • 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
  • 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
  • 1
    I highly recommend this book, Scaling Software Agility, which will answer at least some of your questions. books.google.com/books/about/…
    – user95208
    Jun 28 '13 at 19:38
  • 1
    While Microsoft Windows is large, there is something to be said for how many times have their had releases of a new product and one could pretty easily look at Microsoft's track record to note that the "get the right things done first" wasn't always done as some of the launches weren't that successful. Thus, I'd be tempted to suggest paraphrasing the question and understanding that $100,000,000+ IT projects tend to be quite special and handled quite differently than anything else even though I'd suspect some people would think a million dollar IT project is large.
    – JB King
    Jun 28 '13 at 22:00

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 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.


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).

  • 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. 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 :) Sep 10 '12 at 11:49

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.

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