After watching National Geographic's MegaStructures series, I was surprised how fast large projects are completed. Once the preliminary work (design, specifications, etc.) is done on paper, the realization itself of huge projects take just a few years or sometimes a few months.

For example, Airbus A380 "formally launched on Dec. 19, 2000", and "in the Early March, 2005", the aircraft was already tested. The same goes for huge oil tankers, skyscrapers, etc.

Comparing this to the delays in software industry, I can't help wondering why most IT projects are so slow, or more precisely, why they cannot be as fast and faultless, at the same scale, given enough people?

Projects such as the Airbus A380 present both:

  • Major unforeseen risks: while this is not the first aircraft built, it still pushes the limits of the technology and things which worked well for smaller airliners may not work for the larger one due to physical constraints; in the same way, new technologies are used which were not used yet, because for example they were not available in 1969 when Boeing 747 was done.

  • Risks related to human resources and management in general: people quitting in the middle of the project, inability to reach a person because she's on vacation, ordinary human errors, etc.

With those risks, people still achieve projects like those large airliners in a very short period of time, and despite the delivery delays, those projects are still hugely successful and of a high quality.

When it comes to software development, the projects are hardly as large and complicated as an airliner (both technically and in terms of management), and have slightly less unforeseen risks from the real world.

Still, most IT projects are slow and late, and adding more developers to the project is not a solution (going from a team of ten developer to two thousand will sometimes allow to deliver the project faster, sometimes not, and sometimes will only harm the project and increase the risk of not finishing it at all).

Those which are still delivered may often contain a lot of bugs, requiring consecutive service packs and regular updates (imagine "installing updates" on every Airbus A380 twice per week to patch the bugs in the original product and prevent the aircraft from crashing).

How can such differences be explained? Is it due exclusively to the fact that software development industry is too young to be able to manage thousands of people on a single project in order to deliver large scale, nearly faultless products very fast?

  • 131
    Interesting question. I'm tempted to say the quality of the average worker in the software industry is less skilled and qualified than, say, civil engineering where every engineer has completed a rigorous and intensive degree and likely gained his charter too. Furthermore, the complexity space of large software (eg. an OS, MS Office) is probably much greater even than an aeroplane. Certainly many more places to fail! And a final important point: most software more or less works, even if was poorly written and highly buggy...certainly the cost of failure is normally much less than an aeroplane!
    – Noldorin
    Jul 29, 2012 at 13:58
  • 167
    Find someone who actually works in any of those other industries (but not in PR) and ask them about "large faultless projects". I can virtually guarantee that you'll earn pained laughter. Jul 29, 2012 at 15:50
  • 160
    The realisation of a software project takes seconds or minutes; it's what happens when you click "compile" in your IDE. On the other hand, programming is design. How long did it take to design the A380?
    – Ant
    Jul 29, 2012 at 16:36
  • 55
    That TV program is a hype. They only telecast successful projects. Any channel will make programs for viewers attention.
    – pandu
    Jul 29, 2012 at 18:13
  • 120
    'imagine "installing updates" on every Airbus A380 twice per week...' Imagine enemy robots constantly probing the plane for vulnerabilities while untrained pilots push buttons at random. I bet you'd need regular patches. Jul 30, 2012 at 15:15

31 Answers 31


There is active pushback and resistance from software developers to improving the process of software development. Requirements gathering is dismissed as unrealistic and always resulting in change which means that documentation is always out of date.

On the other hand, agile methods are resisted as well. Daily releases and constant refactoring are presumed to only be allowable for teams that have more time and budget.

There's no guarantee of a culture of professional. The culture and the processes of software engineers varies from company to company and that's one of the problems. You cannot rely on a minimum accepted standard other than "can you code something in language X using libraries A, B, C and get it done by Tuesday?"

This lack of professionalism and active resistance to professionalism is what causes bugs. We can hardly get people to do regular code reviews though there are numerous studies that prove how effective they are at reducing the number of bugs in a product. We can hardly get them to document their own code which can lead to new bugs and leads to wasted days months down the road when everyone's forgotten exactly what the code is supposed to do and why it was built that way.

  • 2
    do you have any data to backup your argument? Aug 20, 2013 at 9:29
  • @HoàngLong no hard data, haven't looked for it yet, only anecdotal. It depends on the workplace, Peopleware is a good starting point for data since the authors of that book actually conducted surveys/studies. Aug 20, 2013 at 20:52
  • 3
    I will check the book. However, I don't think these problems (lack of professionalism, active resistance) don't happen in other industries. Aug 21, 2013 at 2:20
  • Agreed. The cowboy coding mentality is very prevalent. Jun 9, 2014 at 18:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.