views:

302

answers:

4

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 major 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?

+3  A: 

See Continuous-Integration

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

How do you grade your team according to this?

Regards,

StudiousJoseph
Thanks StudiousJoseph for the links, especially the Joel test. I think we score 5. But the question is more about getting a LARGE organization to work together - is there anything particular to that environment? (Those are still useful links, of course!)
Mark Robinson
+2  A: 

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.

Matt S
Yes, Matt S, you are quite right about modularity - thanks. However, often large companies are dealing with a lot of legacy code from when they were small... so the modularity needs to be done retrospectively, and there is never enough time for that... =:-) That is also part of the problem - short term thinking instead of considering long term design.
Mark Robinson
+6  A: 

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 2 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. Its 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 its ugly).

dbyrne
+1 - agreed on both. The adjustment is hard, but I've seen faster release cycles (even for small improvements) raise quality and morale, and those are two big challenges in a large organization.
Will
Mark Robinson
+1  A: 

Boy, great question!

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.

Mike Dunlavey
Thanks Mike Dunlavey for the compliment. Your quotes remind me of The Mythical Man Month. While we use Matlab, we're way beyond getting one or two people restarting the project. This software has thousands of man-years invested in it (see previous comment of mine on legacy code).
Mark Robinson
@Mark: Quoting Bill Clinton, I feel your pain.
Mike Dunlavey
Thanks Mike Dunlavey! I feel it too... =:-(
Mark Robinson