Some highlights from the 2014 QSM Software Almanac, via Phillip Armour’s column in the Communications of the ACM July 2015:
Big teams are bad:
Larger teams cost a lot more, deliver lower quality and seldom save time. Productivity with small teams with the right skills is often 3 to 8 times higher. So if you can’t chop the project up, and find the right staff, reconsider starting it up at all.
Quality is improving:
Especially for “engineering systems”, across the entire industry. Any project that doesn’t measure quality is probably doing so for a reason; i.e., quality is bad and the project doesn’t intend to do anything about it.
Reuse does not usually work:
“Minor enhancement projects with high levels of expected reuse typically cost twice that of new development”. Small changes have big impacts, and software execution environments are constantly changing. On the other hand, it all depends on the definition of “reuse”: E.g., using well-tested open-source components that were made to be reused *does* work.
Agile helps only up to 30KLOC:
Agile is best suited to small projects which don’t require design formalism or extensive integration testing. But some of the Almanac evidence implies that Agile techniques for larger projects may just be immature (i.e., not many large projects reported using Agile, so data is thin).
Projects grow naturally:
On average, project functionality increases 15%, thereby increasing schedule 10% and causing cost overruns of 16%.
Fix the team to fix a problem project:
Brooks’ Law is still in force: Adding people to a project in trouble almost never helps. Get the right people in your project instead to fix the team at lowest cost and least schedule impact.
- You cannot manage what you don’t measure; but stick to basics like schedule, effort, quality, productivity, etc.
- Avoid large teams like the plague, partition large projects into smaller sub-projects, etc.
- Extend project schedule and/or restaff teams before adding additional resources.
- Beware promises of cheap and easy reuse, and plan to rewrite or use open-source components instead.
- The Agile recipe is still being refined for large projects.
Feel free to comment here and if you want to learn how Telegraph Hill can help you manage your software development processes please Contact Us