How can a large number of developers write software together without either a cumbersome process or poor quality software?

I work at a company with hundreds of people writing software for essentially the same product. The quality of the software has to be high because so many people depend on it (not least the developers themselves). Because of this every ma开发者_运维问答jor issue has resulted in a new check - either automated or manual.

As a result the process of delivering software is becoming ever more burdensome. So that requires more developers which... well you can see it is a vicious circle.

We now have a problem with releasing software quickly - the lead time even to change one line of code for a very serious issue is at least one day.

What techniques do you use to speed up the delivery of software in a large organization, while still maintaining software quality?

I also work in a large and cumbersome organization. I've had success implementing several agile software development methodologies, but there are two in particular that I have found especially valuable.

Iterative and incremental development - Keep your release cycle short and tight. Across a large team, if numerous changes are made in between releases, you can find yourself in an integration nightmare.

Large organizations lean towards big project plans with lengthy development time lines. Fight this. Planning a project out an entire year makes no sense when your whole perception might change after the first two weeks of development. Condition your stakeholders to get used to the idea of making small incremental releases and adapting to ever-changing requirements.

Automated Unit Tests - This is a great way to insure you are releasing quality software. The worst bugs are caused by seemingly innocent code changes that have unintended consequences elsewhere. Comprehensive unit tests are maybe the best way to catch this kind of bug. If you can graduate to test driven development or behavior driven development, even better.

Any large organization is going to have some mediocre developers. It's a fact of life. Automated unit testing is a great way to keep an eye on them. Have one of your better developers write their unit tests for them. You will have assurance that at least their code works (even if it's ugly).

See Continuous-Integration

And please read The Joel Test: 12 Steps to Better Code.

There are many ways to improve the process, but the key component is modularity. By clearly separating responsibilities (both in code and in the organization) and defining clear and consistent interfaces, one large team can work as many small teams all tied together.

Wise but gloomy sayings:

• Fred Brooks: Adding programmers to a late project makes it later.

• Gerry Sussman: Programmers combine like resistors in parallel.

• Somebody else: The cost of a project is the number of programmers times the length of the schedule.

Something that might work:

Organize the project so that there is a core application built by one or two people, preferably operated via a language. Then let all the programmers effectively be users of the core, by coding in that language.

I'm thinking of language-based products: SAS, S/R, MATLAB, etc.