Follow this blog:
RSS

Moore’s Law of big tech projects

By | September 1, 2009, 3:00 PM PDT

It always costs more and takes longer. Adding people just slows things down.

–Frederick Brooks

Co-blogger John Dodge has been giving SmartPlanet readers a real treat in his coverage of the ongoing Boeing 787 saga.

But delaying the product a year and watching the top guy walk are no surprise to tech historians. Every project, as it grows in complexity, takes longer and costs more than originally expected.

In computing we saw this first in the IBM S/360.

In the 1960s these computers transformed the industry. They were the first to run the same software across the product line, separating applications from operating systems for the very first time.

The most heart-rending memoir of those days was Thomas Watson Jr.’s Father, Son & Co. Watson’s father created IBM in his image. Watson Jr. transformed it into a computer company, and made the fateful S/360 decision.

One casualty of the S/360 delays was Watson’s brother Dick. Tom gave Dick the project as a stepping-stone to the CEO job. It was Dick’s head that was chopped when failure came.

Why this happens is revealed in another book, The Mythical Man Month, by OS/360 manager Frederick Brooks. In it he describes Brooks’ Law, “adding manpower to a late software project makes it later”. (Buy it now at Amazon.Com.)

This is true because when you hire people you have to train them, and manage them. This takes time. Software development is an intellectual endeavor, so as projects become more software-intensive — and even planes today use a lot of software — Brooks’ Law holds in more places.

I have my own way of describing the process. I call it Moore’s Law of Software. Fact is, there is no Moore’s Law of Software. Hardware gets more complex, and software reaches higher levels of abstraction, but while the former moves exponentially the latter moves arithmetically.

What John’s reporting proves is that Moore’s Law of Software applies to airplanes, too.

Anyone who has ever been inside a big, important software project knows the result of this. Late nights, all-nighters, and giant “pushes” followed by vacations and sabbaticals that are timed to the product life cycle, rather than the developer’s life cycle.

My wife has been in on several of these in 26 years as a programmer, and I can tell you it takes a toll. They say as a result that software is a young man’s (or woman’s) game, but it takes a toll on young programmers, too.

One way technology deals with this is through continual cycles of destruction. If it seems that we’ve been building the same things, over and over, moving from PCs to the Internet to cell phones, and from proprietary tools to open source, we have.

The best way to build something big is to build from pieces, to start from a blank sheet, so the history of technology is one of starting small, building something big from pieces, then starting over.

You can’t really do that with an airplane. Each plane is a separate project, not just pieces but an integrated whole. Software must drive design, fabrication, manufacturing and testing, and given the long lead-times that result much of it must be invented on-the-fly or integrated along the way.

None of this answers the questions Boeing is asking about its 787. It merely explains them. The answers have yet to come.

As Brooks wrote most famously, “there is no silver bullet.” Maybe you can help create one.

Start your week smarter with our weekly e-mail newsletter. It's your cheat sheet for good ideas. Get it.

Dana Blankenhorn

About Dana Blankenhorn

Dana Blankenhorn was a contributing editor for SmartPlanet from 2009 to 2010.

Dana Blankenhorn

Dana Blankenhorn

Contributing Editor

Dana Blankenhorn has written for the Chicago Tribune, Advertising Age's "NetMarketing" supplement and founded the Interactive Age Daily for CMP Media. He holds degrees from Rice and Northwestern universities. He is based in Atlanta.

Follow him on Twitter.

Dana Blankenhorn

Dana Blankenhorn

Dana Blankenhorn has been a technology reporter since 1982, a business reporter since 1978, and a writer for as long as he can remember. His Schwab IRA has a few tech stocks in it, most notably some Intel and Applied Materials bought over 10 years ago. But the vast majority of his tiny fortune (emphasis on the word tiny) is invested in mutual funds. He presently writes for no one else but ZDNet, SmartPlanet and himself. But if you've got an opportunity let him know. If he takes the gig he"ll first add it to this disclosure page.

He writes for SmartPlanet and is not an employee of CBS.

If you liked this, don't miss...
7
Comments

Join the conversation!

Follow via:
RSS
+1 Vote
+ -
RE: Moore's Law of big tech projects
Dana,

Thanks for the compliment. Covering the 787 is treat in of itself.

And I loved Father Son & Company when I read it 15 years or so ago. Tom Watson Jr. took huge risks and really sweated out IBM's expansion in the 50s and 60s against his father's wishes. Didn't he pre-announce the S/360 and kill sales of everything before (1401s? I strain my memory).

Who can forget the picture of him holding the broken cable on his bi-plane that he crash landed in Maine?

Great business saga and family.
Posted by John Dodge
2nd Sep 2009
+1 Vote
+ -
RE: Moore's Law of big tech projects
Another comment if I may: software in some regards is infinitely maleable. You can always start over. If you do that with a giant metal and composite structure like a plane, it's a disaster. The 787 is 99.999999 finished and there is no turning back short of some terrible design flaw or worse.

I agree that adding people can slow down the process. But if Boeing is being straight with us, the path is firmly set....there again, that's what we thought before.
Posted by John Dodge
2nd Sep 2009
+1 Vote
+ -
RE: Moore's Law of big tech projects
You said, "The best way to build something big is to build from pieces, to start from a blank sheet, so the history of technology is one of starting small, building something big from pieces, then starting over."

I say, the best way to build something big is to assemble from stable sub-assemblies, minimizing risk and speeding up assembly. I postulate that your arithmetic law of SW is based on the same.

Nobel Prize Winner Herbert A. Simon gave a lecture at MIT in 1968 on the architecture of complexity. His analogy was based on watchmakers. Tempus's watch was built part by part from 1,000 parts. Every time he put it down to talk to a customer, it fell apart. Hora's watch was built of stable sub-assemblies of 10 parts each. When Hora put down his watch, on the average only about 5 parts disassembled. Hora was much more successful at completing watches on time than was Tempus. See, "The Sciences of the Artificial," Herbert A. Simon (1969, MIT Press, P. 91).

As Hora's watch grows more complex, assembly time grows arithmetically with the number of new parts and sub-assemblies.

The same is true of SW. OO allows us to build from stable components or stable patterns. As a result, SW development times today are more predictable than in the past for same sized efforts.

paultallard@hotmail.com
Posted by paultallard
2nd Sep 2009
+1 Vote
+ -
RE: Moore's Law of big tech projects
It's a pity that projects cost money ; if not for that, things could be allowed to "take as long as they take," rather than be rushed along by nontechnical (i.e. monetary, financial, cash-flow) factors.

On the other hand, perhaps it has always been thus. The patience of kings with their hired / kept artists and craftsman cannot have been infinite; did Moore's Law then apply to e.g. the creation of statuary and paintings and ships?

I find it difficult to separate out the effects of Moore's Law as such from those of just plain trying to go too fast. Has anyone studied the variation in outcome if -- aside from time-to-market considerations -- the "same" project were attempted "quickly and hurriedly" versus "slowly and patiently?" If they have, what were the results?
Posted by Xnert
2nd Sep 2009
+1 Vote
+ -
Dear John
Did I tell you I named my son for you without knowing it?

I think software becomes less and less malleable as it comes down to the end of the process. Once you have your requirements, and then your detailed design, you're going where you're going.

Of course, when the new software has to replicate what really old software did you really get into the weeds. You're not just talking about replacing the main line but thousands of offshoots.

This is happening regularly throughout America. Think of assembly language programs being rewritten for Cobol then being rewritten for a server-based architecture.

This sort of stuff can quickly get bigger, and nastier, than an airplane. At least you know what the airplane is supposed to do -- fly. The software? Not so much, because it does so many things.

Posted by DanaBlankenhorn
2nd Sep 2009
+1 Vote
+ -
Dear Paul:
You're right. Stable sub-assemblies has been the dream of software design for 20 years now.

To a certain extent one big advantage of open source is it allows for this. You can grab hunks of code and have an ad-hoc sub-assembly. And if the pieces don't fit into the jigsaw, you at least can see the code and can mash it about ti make it fit.

Getting to this point, however, has taken, what, 60 years of trial-and-error? Mostly error.
Posted by DanaBlankenhorn
2nd Sep 2009
+1 Vote
+ -
Moore's Law
Moore's law applies to hardware. It turns out we can get exponential improvements in all sorts of hardware. Not just chips, but fiber optics, hard drives, even radios. (802.11n is 10 times faster than 802.11g.)

With software, not so much. Sure there are improvements when you go to higher levels of abstraction. Tools improve. But most programmers are still writing code by hand, when you get right down to it. And they're debugging it by hand.

I tried to learn Java a year ago. For someone who grew up on English -- where the rules are constantly changing -- it was incredibly complex.

But some people can do it. My wife, for instance, is a great programmer. Plus she knows English, so she's a double threat. Plus she's pretty good with people, a triple threat. A rare breed.

How many programmers are like that? Not many. Which brings us back to Brooks. The fact that programmers are human, and can't be plugged-in, swapped out like software sub-assemblies, only adds to the complexity of managing a big project.
Posted by DanaBlankenhorn
2nd Sep 2009
Join the conversation
Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]

Join the SmartPlanet community and join the conversation! Signing up is fast and free. Don't wait -- we want to hear your opinion!