Scaling

The Most Expensive Problem in Tech

In 1965, IBM released the System 360 with its associated operating system, OS/360. This was the largest computer development project ever attempted, and it cost $5B, equivalent to $38B in 2013. IBM was almost broken by this huge expenditure, and by delays in delivering OS/360. However, they persevered and they won the prize, becoming the largest, most profitable, and most powerful corporation on earth as the System 360 grabbed a monopoly position in datacenters across the world.

The leader of the OS/360 project, Fred Brooks, came under incredible pressure. He observed that in complex software projects the productivity of individual developers degrades to the point where “adding manpower to a late software project makes it later.” He wrote a book analyzing the problem called “The Mythical Man Month,” and eventually retired to academia.

Fifty years later, the same problems are with us, and we still read the Mythical Man Month. It’s still true that big software projects are the most expensive and dangerous investments in the high-tech business. More than half of large projects never finish. Some of these are the $100M government agency disasters that you hear about on the news, and some of them are private problems that show up in bankruptcy court.

Big projects are a huge drain on individual productivity. The statistics in Software Assessments, Benchmarks and Best Practices put numbers to the scaling effect. Productivity is measured at 15 function points per developer month for software having 100 function points, declining to 5 per developer month for projects having 10,000 function points, at which point 67 people were involved. The author notes that "projects having more than 100,000 function points are more likely to fail than to succeed." Typical staff size on these projects was 690. There lie dragons.

Scaling problems also afflict small projects. For example, when you go from 1 person to 2 people, you get a big decline in developer productivity. I usually estimate that you need two developers working 40 hours per week to replace one developer working 60 hours per week. That is exactly why good developers work such long hours. Improved scaling ratios will have a disproportionate benefit for small teams that need vacations.

A modern solution to the problem is to shrink the size of programming teams. We improve the productivity of individual developers by giving them better tools, better programming environments, and more shared open source code. Because each developer is more productive, you can build the same software with a smaller team. Working in a smaller team adds additional productivity. So, the multiplier effect works in reverse, and a team of 10 can do what a team of 100 did in years past.

Another modern solution to the problem is to eliminate big projects by chopping them up into smaller services. We will explore this tactic later.

However, eventually those services get integrated into a big system. Some projects are just big. Intelligent systems with big data are big. Data and phone networks are big. Like IBM, the platform providers that can build and manage these big systems will win big prizes.

Fortunately, we have new tactics for managing these projects that have evolved as the Internet has grown. Brooks warned us that there is no silver bullet that can kill the beasts that afflict large projects. However, the following pages will present a bag of silver shrapnel.

This chapter is under construction. We will soon post new content here on subjects like:

  • Scalable Agile
  • Eliminating batches and meetings
  • Dependencies - and how to vanquish the Mythical Man Month
  • Service architecture
Back To The Top ↑