Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses Transportation

Excessive Modularity Hindered Development of the 787 200

TAGmclaren writes "The Harvard Business Review is running a fascinating article exploring the issues facing Boeing's Dreamliner. Rather than simply blaming outsourcing, as much of the commentary has been focused on, the article delves into the benefits of integration and how being integrated when developing a new product gives engineers more degrees of freedom. From the article: 'Historically, Boeing understood that, and had worked with its subcontractors on that basis. If it was going to rely on them, it would provide them with detailed blueprints of the parts that were required — after Boeing had already created them. That, in turn, meant that Boeing had to design all the relevant pieces of the puzzle itself, first. But with the 787, it appears that Boeing tried a very different approach: rather than having the puzzle solved and asking the suppliers to provide a defined puzzle piece, they asked suppliers to create their own blueprints for parts. The puzzle hadn't been properly solved when Boeing asked suppliers for the pieces. It should come as little surprise then, that as the components came back from far-flung suppliers, for the first plane ever made of composite materials... those parts didn't all fit together. Time and cost blew out accordingly. It's easy to blame the outsourcing. But, in this instance, it wasn't so much the outsourcing, as it was the decision to modularize a complicated problem too soon.'"
This discussion has been archived. No new comments can be posted.

Excessive Modularity Hindered Development of the 787

Comments Filter:
  • No specs? (Score:5, Insightful)

    by BVis ( 267028 ) on Wednesday January 30, 2013 @09:36AM (#42737255)

    So Boeing told the contractors what they needed to build, but didn't give them hard specifications? What the hell? Two things:

    Boeing needs to have their collective asses kicked for doing it this way, and:
    The subcontractors should never have agreed to the work without specs first.

    The first one is probably the result of Boeing not wanting to spend the engineering dollars to develop the blueprints, and the second is due to the enormous amounts of money involved in making the parts.

    Now that I know this, you'll never catch me on one of those abominations. What the hell was Boeing thinking?

    • Re:No specs? (Score:5, Insightful)

      by bunratty ( 545641 ) on Wednesday January 30, 2013 @09:45AM (#42737341)
      No, the problem wasn't no specs. The problem was that the system was designed on paper first, without actually building it. Then the specs for the individual pieces were created, and those individual modules were built from the specs. The idea was that then the parts were completed, they would be integrated and work perfectly together. Of course, that never happens because when the pieces come together for the first time, unanticipated problems occur. This is why early integration [ibm.com] is a good idea and is part of the philosophy of release early, release often [wikipedia.org].
      • by vakuona ( 788200 )

        Completely agreed. Now, I know that making a phone is not the same as making a plane, but when Apple creates a new iPhone, they make the whole thing in the US first, test it, refine it, then ask manufacturers to build it to specs they know will work.

        Maybe such a development process would be too expensive for a plane, I don't know, but it sure makes it easy to figure out what isn't working properly.

        Any manufacturer worth their salt (and Boeing is one) should be able to fully prototype their product prior to

        • Re:No specs? (Score:5, Insightful)

          by DerekLyons ( 302214 ) <fairwater.gmail@com> on Wednesday January 30, 2013 @01:04PM (#42739771) Homepage

          Any manufacturer worth their salt (and Boeing is one) should be able to fully prototype their product prior to outsourcing bits of its production (except for things like batteries). But any parts that needs to fit together very precisely should be prototyped first.

          Welcome to the 21st century, I hope your trip from 1950 was a comfortable one! Here in the 21st century computers have advanced to the point where we don't need to physically prototype things anymore - it can, and has been, done digitally for well over a decade now. In fact, one of the most complex things that man is currently building (a nuclear submarine, something else new to you but take my word on it) are now routinely and successfully designed and built without any physical prototype.
           
          Seriously - you and a bunch of other commenters are utterly clueless as to the state-of-the-art of over a decade ago. Boeing has built (IIRC) three new aircraft now (plus major upgrades like the new 747) using completely digital design, visualization, and validation tools. While it's not entirely a mature technology, it's not new and very complex vehicles are and have been in service for years that were designed and built using it.
           
          Prototyping persists with smaller items because the requisite systems and software are so expensive, and is enabled by the fact that the teams involved are relatively small and simple, physically located in one place, and the prototypes are relatively cheap and new ones can be turned around (at worst) in a few weeks. On the other hand, a mockup/prototype of something like a nuclear submarine or a major aircraft can cost tens of millions of dollars (or more) and take a year or more to assemble. To assume that the latter must prototype because the former do is... ludicrous at best.
           
          The problem here isn't lack of prototyping, it appears that they tried to extend the process too far and the management systems weren't weren't set up properly to handle the new process.

          • by vakuona ( 788200 )

            You are comparing a mass produced product like an aeroplane with a submarine that is pretty much built "money no object". Computer simulation has not yet advanced to the point where you could trust it completely. If it was that easy, no formula 1 team would need a wind tunnel. And the FAA would not require test flights before letting a plane be flown commercially. The computer said everything will work right.

            There is no substitute for a prototype. Not yet anyway. And certainly not for anything more complex

      • by BVis ( 267028 )

        I stand corrected. Maybe I should read linked articles first..

        But, I still think it was a case of being penny wise and pound foolish. If I read you correctly, they saved some money by not building the prototype themselves, but then got bit on the ass by the fact that that's a really bad idea and lost money in the long run. Typical corporate thinking. If it costs less TODAY, then that's what you do.

        • yes you should...

          at the end they talk about how management from McDonnel Douglas was possibly to blame because in the takeover several "top" people from McD took over the top posts at Boeing, and these guys had the defence contractor mentality where you spend a little amount on R&D and expect the DoD to keep on handing cash over to you regularly until you can't milk it any longer. That meant that tried to cost-cut as much of the design as possible up front.

          I think it says a lot about defence spending th

      • Re:No specs? (Score:5, Informative)

        by idontgno ( 624372 ) on Wednesday January 30, 2013 @09:55AM (#42737489) Journal

        This.

        I'm a systems engineer, which means that integration is pretty much the only reason my job exists... for projects (hardware/software/everything) which are too big to continuously integrate. Projects that are modularized by design, and very often subcontracted as well.

        If the first time you're integrating your product is the first production run, you're too late. You should have had a prototype. You should treat the first production samples AS prototypes. (The wisdom of the "never buy the zero revision of anything" is in this.)

        But, yeah, that's expensive. It's cheaper to assume that every subassembly will be perfectly built to perfect specifications, and that interfaces just magically happen, and that integration is just sticking the pieces together and turning a few screws.

        • In Appliances, we prototyped, had test samples of new parts build from the production molds, built models for test and test the bejesus out of them. THEN we had two test production runs, tested the heck out of samples of THOSE, then released for production.
        • I see different but related issues in software engineering. There is a tendency for developers to want to turn their applications into something like an operating system. So instead of tightly integrated modules it becomes a bundle of modules which theoretically do things and can be thrown together when the application is deployed. The result is that the framework which ties the who lot together becomes very complex, and interactions between the modules become very difficult to understand and test. You get

      • by tibit ( 1762298 )

        When it comes to mechanical parts, geometric dimensioning and tolerancing is a solved problem. When it comes to electrical interoperability, one'd think that's a solved problem as well. Someone, or many someones at Boeing and/or at the subcontractors don't know their engineering, that's all.

        • by sjbe ( 173966 ) on Wednesday January 30, 2013 @10:48AM (#42738043)

          When it comes to mechanical parts, geometric dimensioning and tolerancing is a solved problem. When it comes to electrical interoperability, one'd think that's a solved problem as well.

          "Solved problem"? HAAHAHAHHHAAHHAAAAA....

          You don't manufacture things for a living do you? I run a company that makes wire harnesses. We're a contract manufacturer - we don't design things, we just take prints and build what is on the prints. I can count on my fingers on one hand the number of prints we have gotten from customers which were correct and sufficiently detailed such that the product could be built without asking any questions. There pretty much always are critical details left out of the prints. About 2/3 of the prints we see have incompatible parts specified. About half are missing at least one important dimension such as length. About 10% have missing parts and about 25% have incompatible parts. About 20% specify needlessly expensive parts like gold plated terminals that cost more but provide no actual performance benefit. Most of them leave off at least one critical tolerance. I've even seen drawings with dimension in inches and tolerances in metric.

          Why does this happen? For the most part because an alarming number of engineers doing the drawings aren't actually very good at their job. Some of them are just plain lazy. The electrical engineers usually can specify a wire schematic but often have no idea whether something can actually be built or know much about industry standards. The more mechanical engineers (yes mechanical engineers can and do design circuits) tend to create bad designs and specify the wrong parts because they don't know any better. Sometimes they are trying to do a good job but they don't bother to consult manufacturing during the design process and they come up with a stupid design or something that is impossible to build.

          I have run into some good engineers but they are the exception.

          • One would hope that when designing a $200M machine with the lives of 240 depending on it working properly, that you would hire the exceptions.

          • by tibit ( 1762298 )

            I do manufacture things, and it took me 10 years to figure out how to spec things out so that the techs make exactly what I want. The technical problem is solved. The human problem maybe isn't. Human is in having competent engineers. I'd have thought aerospace companies are better than someone who has no clue and a decade to learn it on his own, with nobody else to talk to.

            • I do manufacture things, and it took me 10 years to figure out how to spec things out so that the techs make exactly what I want.

              We've told engineers exactly how to specify products such that they get what they want and most of them proceed to ignore us. For most products we make I can send you a well formatted spreadsheet and if you fill it out completely you'll get exactly the product you want from us. It really isn't all that complicated but does require a certain attention to detail which seems to be lacking.

              The technical problem is solved. The human problem maybe isn't.

              There is no maybe about it. The human component is not solved the problems are not separable. Humans design things and

            • "I'd have thought aerospace companies are better than someone who has no clue and a decade to learn it on his own, with nobody else to talk to."

              "I assume that big companies are hyper-competent" is one of this country's most pervasive and dangerous delusions. The opposite is most often the case; especially when a company has a near-monopoly position and powerful political friends, then doing a good job is not necessary.

          • by k6mfw ( 1182893 )

            About 2/3 of the prints we see have incompatible parts specified. About half are missing at least one important dimension such as length.

            Wow, I thought I was the only one observing this... and people complain to me about being too nit-picky about details.

      • This is why early integration is a good idea and is part of the philosophy of release early, release often

        For software, sure ... but when you're talking about physical things, "release early release often" falls apart.

        With something like a 787, you'd sure as heck never be able to do things like that.

        By the time you have your first version, you expect to be able to put a pilot into it and at least taxi it around and look at flying.

        Rapid release cycles of partly completed software is fine, but it just doesn't

        • by Luckyo ( 1726890 )

          It doesn't apply to anything large and non-physical (like software). You should carefully plan, measure, build, prototype, and only AFTER all this is done, release something.

          Releasing something half finished that isn't software typically means a failure of epic proportions. You can't easily fix something that is already built in real world. Only software is easily fixable via patches. In real world, flaws in build can mean anything from having to fully disassemble your build item to actually having to dump

      • Of course, that never happens because when the pieces come together for the first time, unanticipated problems occur.

        This, IMHO, is also the central difference between science and engineering, and why the former doesn't translate directly into the later. A scientific theory describes a sequence of causes and effects that's valid for an isolated system. So, while every theory can be absolutely true within its experimental constraints, the moment you take more than one and try to make both work together, all those ignored parameters start showing their ugly heads. Or, put another way:

        * Scientific Basis: Theory_1, Theory_2,

      • by AC-x ( 735297 )

        No, the problem wasn't no specs. The problem was that the system was designed on paper first, without actually building it. Then the specs for the individual pieces were created, and those individual modules were built from the specs. The idea was that then the parts were completed, they would be integrated and work perfectly together. Of course, that never happens because when the pieces come together for the first time, unanticipated problems occur. This is why early integration [ibm.com] is a good idea and is part of the philosophy of release early, release often [wikipedia.org].

        Isn't that how all modern airliners are created? I'm trying to remember a documentary about the development of the A380, IIRC the entire thing was designed in CAD, the factories were then tooled and the first plane was created from parts from the same production line as the production run would come from.

        Now it's a little different with Airbus as they manufactured most parts in their own factories, but I can't see how it would be economically practical to create a completely bespoke prototype aeroplane of t

        • Re:No specs? (Score:4, Interesting)

          by OzPeter ( 195038 ) on Wednesday January 30, 2013 @10:50AM (#42738067)

          Isn't that how all modern airliners are created? I'm trying to remember a documentary about the development of the A380, IIRC the entire thing was designed in CAD, the factories were then tooled and the first plane was created from parts from the same production line as the production run would come from.

          The Airbus also suffered from manufacturing problems as the German and Spanish facilities were using a different version of the CATIA CAD tool than the English and French facilities. This resulted in hilarity when modules from different locations did not mate as intended.

          • by AC-x ( 735297 )

            The Airbus also suffered from manufacturing problems as the German and Spanish facilities were using a different version of the CATIA CAD tool than the English and French facilities. This resulted in hilarity when modules from different locations did not mate as intended.

            I don't see how making an initial bespoke prototype would have helped with this. An initial custom made part would have been made exactly to design and therefore perfect; the problems at the factory would only have come to light once the production line was tooled and running.

        • by Luckyo ( 1726890 )

          It's economically practical once you consider the costs of failure if you do not.

        • Most of my experience is with the A380, and the majority of the structure is different from the first few aircraft. Right from the beginning, the 7th aircraft (MSN007) was to be the entry into service aircraft, and the first few aircraft were the test aircraft (some eventually sold to customers after modification). You do not make them in a one-off fashion, because you're also prototyping your production process, but the first aircraft is pretty much a prototype. While the first one is being built and teste
      • The problem was that the system was designed on paper first, without actually building it.

        o.O How exactly are you going to build something without a design to build to? Even if you're going to build a mockup or a prototype, you can't use it to iterate a design that doesn't exist. That being said, designing on paper and then building (or at least a prototype or a mockup) is pretty much how everything in the physical world is built.

        That being said, Boeing has experience with designing on paper (act

      • how can you apply software development philosophies to an aircraft?

        iterating and deploying versions of software costs nothing compared to engineering, building, assembling and testing (for hundreds of hours) a flying MACHINE. if a single component has a "fatal error" - you need more engines, airframe, avionics.. etc. something like this MUST be designed and tested using computer modeling at least initially, because full "end to end" testing for every iteration is cost prohibitive... not just in time/money,

      • The odd thing is that IIRC Boeing and Lockheed were among the first to design machines (airplanes in their case) entirely in CAD with 3D modeling of the entire plane, including part fitting, wiring, ducting, etc. I would have thought that they would have provided that capability as part of the outsourcing agreements. This problem need not have happened even with the outsourcers doing the part design, if they could also test fit the parts into the 3D design. Perhaps there were proprietary and/or security

    • I actually logged in for this response...

      Do you REALLY think that is accurate? Do you really think Boeing put the plane together with a bunch of non-spec'd parts? Do you really think that a plane would get off the ground with that type of engineering? Seriously?

      An MBA put his two cents together and came up with a penny and you bought it. Most likely there was a lot of back and forth over specification early in the project as prototypes were being built. That does not translate into substandard final designs

      • by BVis ( 267028 )

        Do you REALLY think that is accurate? Do you really think Boeing put the plane together with a bunch of non-spec'd parts? Do you really think that a plane would get off the ground with that type of engineering? Seriously?

        I think that if the bean counters decided that was a good idea, and gave it to the engineers to work on with inadequate support, it's possible that the engineers, being responsible and ethical, made the impossible happen through serious overwork.

        If I understand bunratty's response above, it

      • Aside from the intent of the article, Boeing did indeed put together the first 787 with non-specced parts - in their haste to make the 07-08-2007 roll out date (7-8-7), Boeing failed to order aviation grade fasteners with enough lead time from their suppliers and they literally had to buy a batch from your every day DIY store, and replace them at great cost and effort afterward. One of the reasons the first four 787s have been written off and will never be sold (the original intent was to sell all the cert

        • I'm not sure where you got that information, but the only problem with the fasteners on the 787 had nothing to do with where they got them... as they are custom designed for this application. It had everything to do with the way they were installed. The problem was that the fasteners were not installed per the specification which caused them to have less holding power than the specifications said.

          Those fasteners were designed to hold the composite components to the titanium sub structure, and even in t
          • It comes from direct involvement in the program, and yes the first 787 rolled out had approximately 60% of its fasteners as installed being non-aviation grade, sourced from the same suppliers as any non-aviation manufacturer would source them - they all had to be drilled out and replaced later on at great cost and effort, using oversized fasteners due to the increased hole size.

            As I noted in my original post, Boeing failed to source the correct fasteners with enough lead time from its usual supplier, leadin

    • by vlm ( 69642 )

      rather than having the puzzle solved and asking the suppliers to provide a defined puzzle piece, they asked suppliers to create their own blueprints for parts. The puzzle hadn't been properly solved when Boeing asked suppliers for the pieces.

      Using some computer science-lite language their design and physical parts "networks" used to be a hub-n-spoke topology. That has always worked pretty well. This time around they tried something like a fully connected mesh for design (because in real world engineering, unlike CS, practically everything affects everything) but they maintained the hub-n-spoke topology for physical parts. There's a bit of a mismatch there.

      I believe the hope -n- dream was forcing the subs to mesh with every other sub would re

    • This gives yet more evidence of the flawed nature of the MBA ideology of management methods being independent from the technical processes of what is actually being managed. There is no substitute for hard won knowledge slogging through the real details of industrial processes. I have said it before, and I'll say it again: the cult-like ideology of MBA managers is driving America into the ground.

    • sounds like agile aeronautics to me. You hear these horror stories all the time. Now the problem isn't with the methodology, it's in the execution. You need the client 100% on board with the process. You need to stick to your scrums. You need to add new functionality requests to the pool and allow your timeline to shift.
  • by pecosdave ( 536896 ) on Wednesday January 30, 2013 @09:39AM (#42737277) Homepage Journal

    I suspect that with the mindset of a government contractor they told a bunch of different places sort of what they wanted, but not where it had to be or what it was going to plug into. Measurements, plugs, protocol standards, bolt holes, shape - they all matter - and "on a plane" doesn't answer most of the questions.

  • by astralagos ( 740055 ) on Wednesday January 30, 2013 @09:40AM (#42737289)
    Systems design in engineering basically involves drawing a box around a bunch of parts and saying "this is a system". The interfaces after that are hopefulyl clean -- good systems design does that, but implicit in the choice of a system breakdown is efficiency loss. I might not, for example, think about the fact that the giant engine at the heart of my car could also run heating. There's this long term conflict in engineering between the need to abstract, which enables all forms of delegation, including outsourcing, subcontracting and even building teams, and the loss of efficiency. Good engineers learn things at an almost inexpressible level,developing jargons for the systems under their purview -- in the case of Boeing, there was literally one guy who was their expert on cabling. If you wanted to submit a drawing change, he could envision the change in the cabling of the plane and whether the change was physically possible. That's always been the bane of system abstraction - you find these things that have to cross systems and, if you don't recognize them early enough, they come back to bite you in all sorts of creative ways. Kelly Johnson was a big believer in this. His rules for skunkworks explicitly required that engineers had to be within a specific number of feet of the shop floor -- that way they weren't too divorced from the reality of the products they were making. You see this in the design of a lot of the early computer systems as well, parts bolted together in weird ways before we started developing this high-level view of what systems actually made up a computer.
    • by fermion ( 181285 )
      Exactly what I was thinking. The issue is not modularity, but not defining interfaces. Modularity is nothing new, and I don't think there is anything wrong with the approach. The overall system, however, has to be defined. I can't imagine that Boeing did not do this. I suspect the pieces that did not fit together was mostly an issue of quality control and cost. For instance, I recently bought a long micro USB cable. The specs for the interface, the microB USB connector are well documented and any com
  • This is what happens with subcontracting you give up to much control and people in the contracting line cut corners where they can.

  • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday January 30, 2013 @09:44AM (#42737331) Journal

    Obviously, Boeing should simply have specified that all the contractors deliver components that accept and output plaintext, and then used pipes and awk to cobble the pieces together into a working system! What could possibly go wrong?

    • And all the software on the subcomponents must be written in Ada. ;-)
    • Obviously, Boeing should simply have specified that all the contractors deliver components that accept and output plaintext, and then used pipes and awk to cobble the pieces together into a working system! What could possibly go wrong?

      As long as they did the scripting in VI... nothing. Emacs on the other hand?? Phew!... don't get me started.

  • By "hindered development," do they mean "made it harder?" If so...fucking duh. That's what happens when you try a new approach to building something...but that's not necessarily a reason not to innovate, and the fact that mistakes were made isn't necessarily an indictment of the activities that took place in the course of that innovation.

    Coming up with a new way of building a large commercial airliner is not going to be easy, and you're going to make mistakes. The article seems a little light on details;

  • Engineering (Score:4, Insightful)

    by the eric conspiracy ( 20178 ) on Wednesday January 30, 2013 @09:48AM (#42737385)

    Boeing didn't want to hire all the engineers needed to design the 787. So when they outsourced these subsystems they also counted on their suppliers to do the engineering of these subsystems.

    The problem is that engineers are not fungible. Boeing didn't appreciate this, any more than the software industry did when it started outsourcing.

    An aerospace structural frame engineer is not the same thing as a marine structure engineer. There are huge differences in the body of experience despite the fact that they both use the same tools.

    This was the primary cause of the delays Boeing had. It will continue to be a problem for anyone who tries this sort of outsourcing.

    • by tibit ( 1762298 )

      The batteries are small. They should have simply swapped them out for a tad heavier and larger Ni-MH units. They went to unproven technology for savings of tens of kilograms and tens of liters of volume over the whole plane. They are stupid. That's all. There's a point where the savings are too small to risk a whole new battery tech. It's not an all-electric plane where it'd be a big deal. Those batteries are relatively small, relatively light, and don't need such a level of optimization and risk taking.

      • This is a good point. Apparently the plane has about 4.4 kWh [wikipedia.org] of battery weighing 57kg. I could build a pack out of off-the-shelf gell cells weighing 133kg. It'd take 54 of the standard 12v 7Ah ones.
  • Wow, they crowd-sourced the design of a wide body aircraft?

    So it's their reputation on the line, and likely a lot of the legal liability .. but they gave the suppliers reign to design their own parts?

    That sounds like an epic fail in engineering to me. The 777 was a marvel in that every part had been designed and modeled in a computer before they ever built anything -- this sounds like a hodge-podge of parts.

    At around $200 million a pop or so, that sounds awfully risky.

  • It wasn't outsourcing the production, it was outsourcing the design that was the problem. Particularly outsourcing the design of subsystems to different suppliers. You don't know if the pieces will work together until they come back home. It's not like an engineer at supplier 1 can walk down the hall and talk to a guy working on a part at supplier 2, but this does happen when you're all under one roof.
    • by tibit ( 1762298 )

      It's the 21st century. It's not like Skype is a new thing, you know. It's a management fiasco. Boeing managers should have made sure that those engineers from various suppliers do in fact talk to each other, and talk often.

      • by vlm ( 69642 )

        Boeing managers should have made sure that those engineers from various suppliers do in fact talk to each other, and talk often.

        If they put resources toward general contractor-type work that eliminates the whole purpose of outsourcing / eliminating the general contractor work. "We'll pay you guys to do it, but since you won't, we'll do it too, to save money"

        Operating in direct opposition to the bosses new management style is probably career limiting.

        • by DarkOx ( 621550 )

          Boeing managers should have made sure that those engineers from various suppliers do in fact talk to each other, and talk often.

          Right in the era of NDAs and intellectual property being regarded as our chief output, that is probably impossible.

      • by DCheesi ( 150068 )

        Great in theory, but in practice it's just not the same. Even if the different contractors are introduced to one another, they're still not really familiar with each other, nor do they necessarily view each other as being on the same team. Collaborations like this just work way better when everyone is working under the same hierarchy and getting their personal paychecks from the same place.

        • by tibit ( 1762298 )

          This may well be, but it's a starting state. People can learn to work around it -- when properly guided. That's where the management comes in.

    • by ceoyoyo ( 59147 )

      That was an awfully long summary to say "it was outsourcing." But the submitter obviously likes to hear himself talk so he gave it a different name.

  • Was not a Beech ðe first composite airplane?

  • From the BBC story [bbc.co.uk]:

    "I think people had their fingers crossed that it was a battery fault... it looks more systemic and serious to me. I suspect it could be difficult to identify the cause," [Keith Hayward, head of research at the Royal Aeronautical Society] said.

    I would hope the folks in change of designing and building aircraft would depend on measurements and calculations, not crossed fingers. Did they also consult a Ouija board?

    • by vakuona ( 788200 )

      I think the article (and the person talking) meant that they hoped it was a battery problem because they would then have isolated the problem to a single component, which is much easier to fix.

      If the problem is systemic, then it can be orders of magnitude harder to fix. For example, is it because the components, whilst each individually OK, behave in strange ways when combined in a certain way. Is the issue an emergent property of the whole system or only of part of the system? And which part. Is the part t

  • Burt Rutan's beautiful creation holds that title.
    http://en.wikipedia.org/wiki/Beechcraft_Starship [wikipedia.org]

  • It's easy to blame the outsourcing.

    Ok so if it wasn't outsourcing what was the problem?

    But, in this instance, it wasn't so much the outsourcing, as it was the decision to modularize a complicated problem too soon.'

    Oh, so it was outsourcing, they were just trying to outsource as early as possible so they won't have to pay engineers to develop the specs.

  • Boeing (Score:5, Interesting)

    by Anonymous Coward on Wednesday January 30, 2013 @10:01AM (#42737565)

    There was a short article on the Dreamliner in the latest New Yorker magazine REQUIEM FOR A DREAMLINER? . Quote Surowiecki :The Dreamliner was supposed to become famous for its revolutionary design. Instead, it’s become an object lesson in how not to build an airplane.
    To understand why, you need to go back to 1997, when Boeing merged with McDonnell Douglas. Technically, Boeing bought McDonnell Douglas. But, as Richard Aboulafia, a noted industry analyst with the Teal Group, told me, “McDonnell Douglas in effect acquired Boeing with Boeing’s money.” McDonnell Douglas executives became key players in the new company, and the McDonnell Douglas culture, averse to risk and obsessed with cost-cutting, weakened Boeing’s historical commitment to making big investments in new products. Aboulafia says, “After the merger, there was a real battle over the future of the company, between the engineers and the finance and sales guys.” The nerds may have been running the show in Silicon Valley, but at Boeing they were increasingly marginalized by the bean counters.

    Read more: http://www.newyorker.com/talk/financial/2013/02/04/130204ta_talk_surowiecki#ixzz2JTGx7SPc

    • by fnj ( 64210 )

      MBAs are like politicians. When they need to be bitch slapped and put away, they end up untouchable. But you can't effectively run a country like that, and you certainly can't run an aircraft building company like that - except run it INTO THE GROUND in both cases.

  • Post-web people may like to read what was all the rage in the early 1990's: the deep philosophy of software development. Doug Lea has a concise summary [oswego.edu], so you don't have to read several hundred pages. And here's a quick direct quote [google.com] from Christopher Alexander I just now Googled:

    ...it is not possible to make something beautiful, merely by combining fixed components.

  • Boeing built it in pieces because they had to be able to sell the plane to foreign countries. It's a tremendous sales aid being able to point to parts of the plane being built by the country interested in purchasing the plane. This is why it's a mess of a build.

    • Almost 40% of a Boeing 777 by weight is foreign sourced (not including engines) so they didn't have to build it n pieces to include foreign suppliers - aside from that, the point of the article is that Boeing also gave the job of detailed design definition to the outsourced suppliers, and that is where the issue comes in.

      Aircraft have been built in pieces for decades before the 787, for example all Airbus aircraft since the A320 in the mid 1980s have been built as prefabricated sections and joined on the FA

      • by geekoid ( 135745 )

        " Airbus have only had one major issue with this approach"
        What? no, not true at all.
        Bad Cockpit design,. bad wiring, premature stress cracks in the wings.

        " it worked perfectly for every aircraft before.
        all airplane have items that " worked perfectly for every aircraft before." right up until it crashes. It's a nonsense statement.. at BEST it shows a company not testing old systems on new air craft.

        • "Bad cockpit design" - no worse than any other. Care to elaborate?

          "Bad wiring" - again, care to elaborate? If you mean the A380 debacle, did you miss the part of my point where I explicitly mentioned that as the only major issue they had with their approach?

          "Premature stress cracks in the wings" - using a new production process in an Airbus factory, which would have occurred if Airbus produced the wings 100 yards from the FAL anyway. Hardly a great argument against my point.

          The design and build process Ai

  • In this artcle they cite a 2001 Boeing paper [amazonaws.com] which I find very interesting.

    All those MBA bosses should have a look, it seems very few have learned any lesson since then.

    The point is made that not only is the work out-sourced; all the profits associated with the work are out-sourced, too.
    ...
    A strong warning is included about the perils of sub-optimum solutions in which individual cost are minimized in isolation.

    It is quite enlightening, given that their problem today could very likely come from those interdepartmental interactions not thoroughly planned enough.

  • I have news for you. This is how most things are developed.

    Homes are built from standardized components, as are production machines, cars, computers and even software. Often, we pick our components first, with only a hazy idea of the finished product. We think we know what we are developing, but after its built, it usually looks quite different than first imagined.

    The key is Boeing is developing a much more difficult design and this is their first attempt at using this method. It is understandable that

    • true, homes are built from standardised components but you'll find those components are very well defined and fit together well enough to work. That was the problem with this - the pieces were not well defined enough to fit together well.

      Of course a brick is less complicated than an aircraft component, but even then you know exactly what you want to build, and you work out how its going to be put together and then you build it. No-one thinks "I'll build a house, I'll need, umm, some bricks and some wood" an

  • by EmperorOfCanada ( 1332175 ) on Wednesday January 30, 2013 @10:49AM (#42738047)
    Obviously a large project has to have an overarching design and direction but a great example of a failed top down aviation design would be the Space Shuttle. They designed many of the larger systems in oddly specific waves of a wand and then left it to engineers to actually invent them. A really great example of this failure were the cryopumps for the liquid hydrogen and oxygen. This things had to pump a swimming pool of fuel every few seconds and were beyond anything anyone had done before. Yet they had to fit into a specific space and last 25 flights or more. But what happened was that they pumps could not be built to last more than a flight or two and thus became part of the servicing between every flight. The problem was that they were buried deep inside the engines and were a royal pain to replace. This plus a zillion other similar high level decisions resulted in each shuttle flight turnaround taking forever an costing way too much.

    So if you look at the Space X people they are doing the opposite and seeing how good an engine they can build and then plopping a spaceship on top of that. This is how functional companies that don't have too much MBA management bloat engineer things. But my guess is that instead of Boeing just designing a better airplane with composites and seeing what interesting things could be done they made a long series of "executive" decisions and then told outsourced engineering teams to make square pegs fit into round holes. This would be as opposed to a healthy back and fourth where a high level goal is set, the rubber meets the road engineers give their feed back that changes the high level design which results in more feedback until you have a solid high level design that the engineers are fairly certain they can design.

    I suspect nearly every programmer here has had a taste of this when some MBA type demands a costly feature that when all is said and done will be used by one person to very little benefit; all because there was no real feedback mechanism to say "whoa there dumb feature."
  • is the problem. Well, you save a few pennies in development Boeing, hows that working out for you?

    • Stop.. In manufacturing there's a lot of integration, third party suppliers or outsourcing as it can also be called. All of those have various degrees of risk associated with them. When you're talking about the scale of what Boeing did on the 787, I think it created new management challenges that they weren't fully expecting and the result was cost overruns and schedule delays. They've always integrated and outsourced with partners. For example I know that they don't make their own nuts and bolts, or ri

  • They should have hired Linus Torvalds to consult and used git for the master blueprint.
  • Maybe they should have had more daily scrums in their agile development process...
  • ... Boeing laid off and retired the people that understood how the pieces fit together. Modular development works fine if you have people that understand systems at a high level and you keep the lines of communication between systems integration (Boeing) and suppliers short.

  • I think part of the problem is that Boeing defined what components they needed, but not necessarily completely how they were to be built or function internally (for things that have internals). For example, they may have specified an electronic component by its inputs/outputs and working/environmental tolerances, but not anything about the internals. In theory, this "black box" approach should work pretty well, but - as we programmers know - side effects, edge conditions and unknowns are a bitch.

    In the

  • I know I'm late for a nice flamefest, but I'm sure someone will point out how Krugman was wrong about this when he discussed it almost two years ago: http://krugman.blogs.nytimes.com/2011/02/19/thank-you-boeing/ [nytimes.com]

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...