Code

Novelty In Software Engineering

A lens for understanding complexity

December 16, 2024

In the 1940s Bell Aircraft used an experimental approach to build the first commercial helicopter:¹

At Gardenville, we built things, tested them, modified them until they worked, and then made the drawings.

— The Bell Notes, Arthur M. Young,

The project manager contrasted this with how they built airplanes:

The main engineering group made drawings, sent them to the plant, and only the project manager ever saw the product fly. This was successful with airplanes because the airplane did not involve unknowns …

— The Bell Notes, Arthur M. Young,

Prior to Arthur Young’s arrival, Bell Aircraft had attempted to build helicopters without success. Meanwhile Young had built working prototypes on his farm. How is it that a successful aviation firm failed while a farmer triumphed?

If we characterize problem-solving as the search for a solution, the domain complexity is a key factor. But with an incremental change to a complex domain, much of the space is already explored. And that’s why with same methods that had failed to build a helicopter, Bell Aircraft built the first American jet airplane. Jet propulsion was an incremental solution (they were even given a working jet engine!).

Meanwhile to create the helicopter, one had to start the “search” from scratch. The helicopter was a novel solution to the problem of a vertical take-off and landing aircraft.

Novelty in software

The experimental development of the helicopter reminds me of Agile - the iterative software development philosophy we use today. Long before “Agile” was invented, Fred Brooks advocated for something similar, that software should not be “built” but “grown”:²

If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach… I find that teams can grow much more complex entities in four months than they can build.

— No Silver Bullet, Fred P. Brooks,

Brooks wrote his paper in the middle of the productivity paradox in IT. The rapid computerization of work had not delivered productivity gains. It turned out that workplace domains were far richer than expected, and the precision demanded by computers hurt as much as it helped. There was too much novelty.

What changed? Anybody that has used a supermarket self-checkout station might attest that computerization still has room for improvement.³ What changed, I think was that we invented a new domain, the World Wide Web. This domain was much better suited to computers and the “Information Highway” took off.⁴ Yes, every company’s website is different, but they are much more alike than their cultures.

New standards, tools and libraries were built for the Web. Knowledge spread. The domain novelty decreased while solution complexity grew.

Today we have fantastically complicated microservices, but little novelty. Perhaps the most valuable function of LLMs is they can generate solutions over infinite domains containing incidental differences in novelty.

Zooming out

Could we one day eliminate novelty to the extent that Agile software development no longer makes sense? After all, we don’t grow helicopters anymore. Surely the return to hard engineering, waterfall-style development is inevitable?

Not so fast. For one thing the costs of engineering projects have ballooned over time. Is that something we want to emulate? For another, unlike hard-ware, software can be distributed instantly and essentially for free. Of course Brooks called this out this too:²

The cost of software has always been development cost, not replication cost. Sharing that cost among even a few users radically cuts the per-user cost. Another way of looking at it is that the use of n copies of a software system effectively multiplies the productivity of its developers by n. That is an enhancement of the productivity of the discipline and of the nation.

— No Silver Bullet, Fred P. Brooks,

Nevertheless when it’s time to write software I believe a useful question to ask is: “So what’s new here?”.

Notes

  1. The Bell Notes, Arthur M. Young.
  2. No Silver Bullet, Fred Brooks, 1986.
  3. Or self-driving cars, smart cities, AI cancer detection etc…
  4. Likewise, will “agents” be the best domain for AI to express itself?

Tags: complexity agile software-engineering