Good practices for large scale development/delivery of software

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.