Our tools & materials are constantly changing... not to mention that every project is different in various ways (though many developers delude themselves into thinking their project is unique i.e. the snowflake effect). I've found the most success when I stick to tools/patterns/strategies that I've had some degree of success with in the past.
Politics between the decision makers, especially in middle management. I see that quite often. They set a budget and deadline but keep changing requirements, arbitrarily choose systems you have to use but also often avoid making important decisions when needed.
Yes, it certainly isn't partially the responsibility of developers.
Surely it's fine that moaning about how doing design before writing code is boring, a waste of time (because it's "just documentation that won't apply at the end of the project anyway"), or beneath them (it's for people who aren't smart enough to write code). I've heard variations on all of these in person, and seen them in comments here on HN.
Gunning for the big glory of "saving the company" by re-writing the whole thing from scratch in Fancy New Language/Framework X certainly has nothing to do with it, right? This happens more often than some might care to admit.
Engaging in ego-stroking/pissing contests about CS trivia and minutiae instead of focusing on the broader engineering tasks and problems at hands is blame-free, yes?
This industry is absolutely packed with very smart people who, from an engineering perspective, fall quite short, mostly because of their own egos at root.
...because the hiring process is very broken, and you end up with a Team that's a mix of a small number of super smart engineers, a good size of average engineers, a lot of incompetent engineers, and a couple of toxic engineers. All with varying levels of communication and soft skills.
Now throw in a good measure of politics with a dash of bureaucracy and you have your answer.
The hiring process hires exactly the people that it was designed to. You do not want a team that excels in every aspect. How would you manage such a team? They would go off in directions you cannot control anymore and you have no way of stopping them taking your position.
I blame changing requirements. I've yet to see a large project which hasn't changed its requirements along the way. On the other hand airplanes are designed tested in small scale for proof of concept and specs are finalised before any production work begins.
Now that you say it, I believe that there are several (military) aircraft projects that have huge delays exactly due to changing specifications. The people making the contracts did not have a clear vision about what they actually want and there are several parties involved who want different things crammed into one vehicle. As the process moves on, the requirements get adjusted to meet the new political power balance.
The commerical planes, I believe, were designed with a clear goal and are in many ways an incremental improvement on the previous (proven to work well) models.
So in essence you need: A clear vision of something that is acutally achievable. Plus you need to communicate that vision.
With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering goes into finding the right materials, the best shape and processing tools. But the finished part is easy to understand.
With software engineering we have abstractions like "sort algorithm" that are easy to understand but many things have so many cross-connections to other parts that in order to understand what is actually going on you have to get really deep into this stuff. Changing a detail in one implementation may lead to unforseen consequences on other, seemingly unrelated, parts. You may rely on undocumented features without even knowing that.
How many cables do you see when you cut a boeing in half? How many of them are essential to operating the plane? How many dangling pointers do you get if you cut your main memory in half? How many of them are of system components?
Whatever technique we have to cut down complexity, hide implementation details behind clear interfaces, separating stuff into easily-to-combine modules makes managing projects easier. I think that the main success factor of python lies in this area.
Then imagine a project that does not have all those modules readily available. That does not have engineers who know it all (and really do, not just pretend) in charge. They rough out a plan and start working on many ends that - when they meet - do not fit together. Add in organizational, personal, psychological problems and the structure wraps in on itself, turns on itself in infighting about how-to-do-stuff, career postions, blame, praise, just surviving or just passively standing by fulfilling orders on paper waiting until everything collapses.
Interoperability and dependency also tends to play a very large part of why IT projects are notorious for getting side tracked, to jump off this post; at my last place of employment, the first major project we tried to tackle was finally migrating off of a legacy server which touched virtually every other piece of software and hardware on the campus due to how the infrastructure had grown over time. Every project was stalled largely due to the fact that everything was so dependent on this one system and the system itself was a complete unknown as it more or less was script-soup written by one guy over the course of 20 years. Detangling and decoupling everything took years, and was only finally completed when the server's mobo went belly-up on us and we weren't able to scavenge a new part.
With a lot of infrastructure projects, you can fairly easily route around dependencies since, luckily, in many cases modern cities have planned for it, or there are natural detours built in, but dependencies in IT can be literally hard-coded, and replacing then is not a minor task.
In Norway big road-building projects involving complex bridges and tunnels are done mostly on time. When they are not on time these days, the delays quite likely come from IT. For example, 2 years ago tunnel opening was postponed by few months due to the need for extra camera testing that came from fixing some software issues.
The IT industry regularly does exactly that. The other engineering disciplines get too much credit for being executed perfectly according to plan and delivering flawless results.
Examples:
Bridges that have cracks. Roads that become too slippery when it rains. Railways that require immediate reconstruction after the first month of operation. Delays, environmental disasters, multi-million projects that become multi-billion projects. Projects that are ten years late...
The Airbus A380 mentioned in the question probably has thousands of defects but it's still a very successful project. On the software side I could mention Windows 10, most triple-A games and Tesla's autopilot. Of course these products have defects. But they're still very successful projects. Give them some credit.
Very funny. I should probably edit my comment to say "may very well have been a successful project" but I like the way you burst that bubble so I'll leave it as it is. ;-)
It would be useful for software developers to really step out of software industry bubble.
I hear all the time about construction projects delays and you get a lot of physical products with faults.
Other thing we as software developers live in is hiring process. I do not even know what could be hiring process for chemical engineer or something like that.
Because most IT projects are not really pure play IT projects? If we do a comparison with construction, once requirements are done, design is completed, it is civil engineers all the way through. But in IT it requires input from non-IT folks and the amount of disconnect is mind boggling. So say creating a product for a construction company, which can predict the stress on a building. It requires coders who have no formal education on this aspect to work with civil engineers who have no formal education on how software works. So both way communication tends to be terrible.
Because we can't estimate things well. We have played with small demos and examples, solved homework problems (in college). We remember how successful we were picking up and coding new APIs and ideas.
That is we often have a proof of concept ready or the skeleton and then declare it 80% done. Then we extrapolate and say, "well I'll a bit more just to finish the last 20%". Except that the last 20% is composed of both boring and unpredictable things. Boring like having to write tests, documentation, find out that it doesn't jive with the deployment hardware, plugging logging, authentication into it, managing upgrade from old versions of software, having meetings with marketing. Unpredictable because in that perceived 20% requirements change. Even more insidious is the market as a whole change. Ever seen it happen - while finishing a major project and about ready to release it, everyone moved on and nobody wants that kind of a thing anymore? I've seen it.
In addition to all the other reasons, the IT industry is much, much younger than other industries. The 'web' itself is only 26 years old, shorter than a single person's career. Punchcards were still in common use in the late 70s, again within the reach of a single person's career.
The gaming industry routinely deliver "large, faultless projects" within 6-9 months timeframe. Searching for "data-oriented programming" gives some hints how they do it. Another part of the story is proper project management.
Insomniac has two studios, one in Burbank, another is in Raleigh. It also does multiple projects at once in the Burbank so no, they are not delivering two console games a year. In fact, since 1996 they've done it only in 4 years (with the second game being a R&C game, which is more of a game design than a programming project) just as many years as they have not released a single game. Each of their big games is 2 years+, just like any other AAA studio. They start pre-production on the next project in the middle of the current one, just like any other AAA studio. 6-8 months in the console games nowadays is either a port (porting a game from one platform to another) or some horrible shovelware you find in the happy meals. In 6th generation a AAA game could be 12-18 months and if you worked really hard you could do something like Rogue Leader in 9. But 6 months is something from the 8 bit era, before Insomniac's times.
Can you name any title that was developed in that timeframe? With yearly release cycles, it's easy to think they're pumping out projects in less than 12 months, but in reality each title takes years to finish, and the yearly releases are accomplished by using multiple studios/teams and pipelining.
The premise is wrong - large complex projects breaking new ground are often late, over budget and error prone in other industries as well.
The question uses Airbus A380 as an example of a complex project that was delivered in just five years. But according to Wikipedia the project started around 1990 which adds 10 years to the timescale, and the project actually had multiple delays https://en.wikipedia.org/wiki/Airbus_A380#Production_and_del... and multiple issues were found (and fixed) after delivery. This is not at all surprising given the scope of the project, but it is strange to present this as delivering a faultless project quickly.
"Airbus cited as underlying causes the complexity of the cabin wiring (98,000 wires and 40,000 connectors), its concurrent design and production, the high degree of customisation for each airline, and failures of configuration management and change control" - does this sound familiar?
Of course, when the model have been designed and tested, it is pretty predictable and low-risk to build the next one to the same specs, just like it is pretty predictable to build a standard building according to well-tested plans. But this is comparable to installing an existing tested software package on an new computer, which is also pretty predictable.
What seems to be missing (correct me if I'm wrong) is bad incentives. Software projects in government tend to be assigned by two ways:
1) via tenders, where it's a race to the price bottom, and the vendors charge massive sums for change requests or simply to fix what should have worked in the first place, but the government must pay additional money in order to not have wasted the entire sum already spent
2) tenders with specs that are customized so only a select few (or one!) vendor hits the criteria (e.g. must have 20+y of government work history, x% of workers must have top-secret clearances) or lock-in; basically "no one ever got fired for buying IBM/Accidenture". The big vendors of course know this and charge govt through the nose.
Another reason especially in government is a lack of client-side controlling, i.e. there is no qualified staff to review code, architectural decisions or cost/time plannings early (if at all). This also hits home for construction projects.
Because you'll be out-competed if you aim for high degrees of 'faultlessness.' Your competitor skips your sound engineering practices, gets to market faster, and "wins."
Two years later, they get breached, 10 million unhashed passwords leaked, and yet they have such a stranglehold on the market that the breach barely affects their bottom line.
Compare that with say, the aerospace engineering industry, where putting out a faulty airplane that crashes, brings with it lawsuits, damages from victims, huge hikes in insurance premiums, and higher demand from consumers for your competitors' models.
Losing a plane full of people is a tragedy. Losing a few million passwords is not. Actually, my email addresses and passwords have been leaked many times and it's not a big deal. Makes a barely noticeable difference to my spam folder.
These are very different levels of risk. Of course they are approached differently.
Just because you've never been adversely affected doesn't mean other people's lives aren't ruined.
What about people who have unsavory things leaked about them? (Gay people still in the closet from their ultra-conservative families? Religious people who leave their faith?) What about people who are blackmailed? What about women's private nude pictures? I think they care whether their accounts are compromised.
We have privacy for a reason. It's valuable. And the more we depend on the internet for our lives, placing our private actions (nudity, conversations with our closest friends and family) onto the internet, the more valuable it is to hack and breach it. The more our society values witchhunts, the more valuable it is to breach security to find new savory details to feed those witchhunts.
Imagine if you took an innocent photo of your toddler, naked, in the bathtub. And then found out it was being traded on a pedo ring. You'd feel pretty violated. And then you found out your home address and your child's school address was posted online there. You'd feel pretty scared at that point.
The most contrived examples you come up with are still vastly better outcomes than 150 people perishing in a plane crash. The stakes are just much, much lower.
We see class actions and government intervention over things like wristbands that give a small percentage of people rashes, antennas that perform poorly if you hold your phone in a certain away, or devices that fail just out of warranty.
I think the difference is they're extensions of laws for more egregious things like; things that electrocute you, things that give you cancer, or things that explode. (I'm sure another factor is that physical things have been sold for much longer than digital things) Since digital things don't have those catastrophic examples, the other violations don't have the same protections.
Challenger was destroyed by a disintegrating solid rocket. Given that a solid rocket cannot be shut down, what kind of software change could ever save them?
Solid rockets that detach. So, at least in theory, could have ejected the rockets. Or detached the shuttle from the whole tank and land. If you can detect the rocket's about to blow, of course.
That question is talking about a TV show that cherry picks the best examples of engineering projects, and shows the results on their launch date. But we see all IT projects and have to live with their ongoing status under daily use, as business grows and changes around the systems. Those are completely different measuring sticks. I'm sure that if you were to go hire people to go find the best IT projects and do a documentary about them, you'd find enough to fill a TV show, too. That doesn't mean there are not failures in both arenas, as well as successes... it just means you see much more when working in IT than you do on TV.
Two key reasons (others have been mentioned): the output is purely digital, and incredibly abstract. Code is very unique in this regard.
As a purely digital artifact, it is highly malleable. Yet its deeply abstract nature, and the complexity enabled by those abstractions, make software very difficult to inspect and understand, compared with the vast majority of things humans make.
I think a lot of the reasons are related to the primacy of the project. The A380 was a bet-the-company move for Airbus and Emirates. This means that practically everyone at both those companies are aligned around the necessity to make the project a success, and there is a broad and shared understanding of the need to shape the world around the project for it's success.
Organisations often fail to realise the strategic importance of big IT projects, and fail to treat them accordingly. "The geeks" are tasked with figuring it out.
Whenever a new subway line is built in a city, years and years are spent moving existing underground infrastructure like sewers, water, gas and electricity. All sorts of weird complexity tends to bubble up around this time. A comparable IT project will typically have requirement 264/B-4: The project will be delivered without changing existing infrastructure.
This again probably has something to do with the sequestration of IT as a staff function. This is absolutely the correct place for the office that builds and supports workstations, runs the Exchange server and manages the Active Directory, but it is not where you anchor a large, strategically important project (IT is definitely an important stakeholder, but they don't own it). Emirates doesn't have a staff office tasked with buying, taking delivery and integration the A380 into the fleet, that is a project that spans the organisation and is run out of the CEOs office.
Tangentially to this, there are the complications around the fact that many large IT projects replace existing systems, sometimes decades old. I'm not sure there really is a good physical analogy to the ways old IT systems creep into and get entrenched in adjacent use cases, often without the system owners really realising. It's like Emirates realising two weeks before the inaugural flight of the A380 that there is something about the ailerons of the new plane that means half of the check-in staff can't get to work.
Regulation, and taking advantage of current practices?
Any aviation or civil engineering project is in a highly regulated environment, and lives can be spectacularly lost if the product fails.
Lawsuits and criminal charges would likely be large and numerous if such a project failed, and was built with entirely new processes and technologies that were seemingly chosen on the whim of a project leader and their people, combined with "something we found on github." (I'm guessing there's no such thing as github for civil or aerospace engineering.)
If your environment constrains you in some dimension, then you're not going to spend much time and resources discovering new ways to stretch that dimension.
Few people see IT as anything but a cost, When companies run a tender, they go with the lowest cost bidder.
Companies that bid, also have twisted priorities, the people who do the bidding, aren't the people that have anything to do with the project, they more onto the next bid.
Its easier to fudge the numbers when you are dealing with something that isn't physically tangible.
In my experience some or all of the following will happen on big software projects...
The sales team will bid unrealistically to get the contract, either by underestimating development time or by bidding too low. They will also ignore the advice of experienced devs an PMs when planning their bid.
On winning the bid there will be a ruthless focus on doing things as cheaply as possible. A PM with no experience of this type of project will be put in charge. The rest of the team will largely be chosen based on availability rather than skills or experience. The positions of software architect or technical lead will be seen as optional.
Whatever PM methodology is chosen (probably Scrum), no one will really understand the finer details of how it works. Work will be divvied up poorly, e.g. tasks that need two people working on it together will be given to one person and vice versa.
There will be no thought given to training. Devs will arrive in to find out they are working on some hyper complex financial system, but they will never be given training on what that system is for or how it works.
Inevitably the specs as defined in the bid document will be discovered to be incomplete or faulty. No one will want to actually change the specs, but somehow the devs will be expected to just deal with it.
If the contract is time and materials based as opposed to fixed price then the contractor will massively over-resource the project meaning you end up with a too many cooks situation.
The client will get wind that there are problems and raise concerns. The PMs and hgh-ups in the contracting firm will claim everything is Okay and demand devs work overtime to get things right. They may also utilize smoke and mirrors to fool the client.
As stress builds among the PMs they will start to micro-manage, this will alienate senior devs who know they don't need to take that and they may leave for pastures new. Junior devs will carry on despite still not having the required skills or experience. New devs will be hired, only to leave soon after when they realise that the place is in a mess.
Eventually the project will be delivered late and full of bugs, yet somehow the contractor firm will claim everything went great and organise a piss-up to celebrate.
There are three levels at work in IT. First, it's important to understand that all IT work is carried out by vendors or providers of some sort. Either a IT vendor or internal IT group which is essentially still a vendor (often shared services) to the business, albeit part of the same company.
This can be broken into three levels of hierarchy.
The executive level is the level VP and above - they write checks. If you don't spend the company's money - you are not at this level. They spend money on programs. They don't know or need to know (or care about) specifics. They are only concerned with the investment and not even individual investments but the organization as a whole.
The bottom level is the IT worker. They are the programmers, managers, etc.. that carry out the specific tasks, do the work.
In between is the (often called Sr. Managers, Acct execs, or VPs in consulting). Not straight sales guys (which is a specific skill, and who are specifically there to close, that's a different breed).
These are the schmoozers. Project people (level 3) have to report to them and they typically hold pretty decent amount of power (reporting to the CEO of a smaller IT consulting or svcs firm, or a COO or SVP in a larger firm). They get credit, sometimes deserved, for bringing in business, so they have power - AND they are often completely incompetent in knowing what to look for and managing a project to success.
They have the power and they don't know what to do, or won't do it. The managers below them, experienced team leads, etc.. know what to do but don't have the power or resources under their control.
It fails at this level, and the level 3 folks (proj mangers, leads, dev, etc..) are not directed appropriately. They may be the greatest team leads and developers etc.. in the world, and the project still fails.
86 comments
[ 3.4 ms ] story [ 33.5 ms ] threadHow do they interact with engineering?
Surely it's fine that moaning about how doing design before writing code is boring, a waste of time (because it's "just documentation that won't apply at the end of the project anyway"), or beneath them (it's for people who aren't smart enough to write code). I've heard variations on all of these in person, and seen them in comments here on HN.
Gunning for the big glory of "saving the company" by re-writing the whole thing from scratch in Fancy New Language/Framework X certainly has nothing to do with it, right? This happens more often than some might care to admit.
Engaging in ego-stroking/pissing contests about CS trivia and minutiae instead of focusing on the broader engineering tasks and problems at hands is blame-free, yes?
This industry is absolutely packed with very smart people who, from an engineering perspective, fall quite short, mostly because of their own egos at root.
Now throw in a good measure of politics with a dash of bureaucracy and you have your answer.
The commerical planes, I believe, were designed with a clear goal and are in many ways an incremental improvement on the previous (proven to work well) models.
So in essence you need: A clear vision of something that is acutally achievable. Plus you need to communicate that vision.
Let me introduce you to the F-35 and let's see how you react to that.
http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=...
With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering goes into finding the right materials, the best shape and processing tools. But the finished part is easy to understand.
With software engineering we have abstractions like "sort algorithm" that are easy to understand but many things have so many cross-connections to other parts that in order to understand what is actually going on you have to get really deep into this stuff. Changing a detail in one implementation may lead to unforseen consequences on other, seemingly unrelated, parts. You may rely on undocumented features without even knowing that.
How many cables do you see when you cut a boeing in half? How many of them are essential to operating the plane? How many dangling pointers do you get if you cut your main memory in half? How many of them are of system components?
Whatever technique we have to cut down complexity, hide implementation details behind clear interfaces, separating stuff into easily-to-combine modules makes managing projects easier. I think that the main success factor of python lies in this area.
Then imagine a project that does not have all those modules readily available. That does not have engineers who know it all (and really do, not just pretend) in charge. They rough out a plan and start working on many ends that - when they meet - do not fit together. Add in organizational, personal, psychological problems and the structure wraps in on itself, turns on itself in infighting about how-to-do-stuff, career postions, blame, praise, just surviving or just passively standing by fulfilling orders on paper waiting until everything collapses.
This also makes it immediately understandable why throwing more programmers at something doesn't always increase the development speed.
With a lot of infrastructure projects, you can fairly easily route around dependencies since, luckily, in many cases modern cities have planned for it, or there are natural detours built in, but dependencies in IT can be literally hard-coded, and replacing then is not a minor task.
Examples:
Bridges that have cracks. Roads that become too slippery when it rains. Railways that require immediate reconstruction after the first month of operation. Delays, environmental disasters, multi-million projects that become multi-billion projects. Projects that are ten years late...
The Airbus A380 mentioned in the question probably has thousands of defects but it's still a very successful project. On the software side I could mention Windows 10, most triple-A games and Tesla's autopilot. Of course these products have defects. But they're still very successful projects. Give them some credit.
http://calleam.com/WTPF/?p=4700
I hear all the time about construction projects delays and you get a lot of physical products with faults.
Other thing we as software developers live in is hiring process. I do not even know what could be hiring process for chemical engineer or something like that.
They must make you do chemistry brain teasers on a whiteboard right?
Being late on an aircraft or building probably comes with financial penalties.
Then the questions are what exactly constitutes a project and what are failures? Taking the example of the quoted A380 example. Deliveries have been delayed: https://www.bloomberg.com/news/articles/2016-12-27/airbus-to...
And the engines the mainstay of a plane have found to be have problems: https://www.bloomberg.com/news/articles/2016-11-18/emirates-...
That is we often have a proof of concept ready or the skeleton and then declare it 80% done. Then we extrapolate and say, "well I'll a bit more just to finish the last 20%". Except that the last 20% is composed of both boring and unpredictable things. Boring like having to write tests, documentation, find out that it doesn't jive with the deployment hardware, plugging logging, authentication into it, managing upgrade from old versions of software, having meetings with marketing. Unpredictable because in that perceived 20% requirements change. Even more insidious is the market as a whole change. Ever seen it happen - while finishing a major project and about ready to release it, everyone moved on and nobody wants that kind of a thing anymore? I've seen it.
[1] - https://youtu.be/rX0ItVEVjHc
Can you name any title that was developed in that timeframe? With yearly release cycles, it's easy to think they're pumping out projects in less than 12 months, but in reality each title takes years to finish, and the yearly releases are accomplished by using multiple studios/teams and pipelining.
The question uses Airbus A380 as an example of a complex project that was delivered in just five years. But according to Wikipedia the project started around 1990 which adds 10 years to the timescale, and the project actually had multiple delays https://en.wikipedia.org/wiki/Airbus_A380#Production_and_del... and multiple issues were found (and fixed) after delivery. This is not at all surprising given the scope of the project, but it is strange to present this as delivering a faultless project quickly.
"Airbus cited as underlying causes the complexity of the cabin wiring (98,000 wires and 40,000 connectors), its concurrent design and production, the high degree of customisation for each airline, and failures of configuration management and change control" - does this sound familiar?
Of course, when the model have been designed and tested, it is pretty predictable and low-risk to build the next one to the same specs, just like it is pretty predictable to build a standard building according to well-tested plans. But this is comparable to installing an existing tested software package on an new computer, which is also pretty predictable.
1) via tenders, where it's a race to the price bottom, and the vendors charge massive sums for change requests or simply to fix what should have worked in the first place, but the government must pay additional money in order to not have wasted the entire sum already spent
2) tenders with specs that are customized so only a select few (or one!) vendor hits the criteria (e.g. must have 20+y of government work history, x% of workers must have top-secret clearances) or lock-in; basically "no one ever got fired for buying IBM/Accidenture". The big vendors of course know this and charge govt through the nose.
Another reason especially in government is a lack of client-side controlling, i.e. there is no qualified staff to review code, architectural decisions or cost/time plannings early (if at all). This also hits home for construction projects.
Two years later, they get breached, 10 million unhashed passwords leaked, and yet they have such a stranglehold on the market that the breach barely affects their bottom line.
Compare that with say, the aerospace engineering industry, where putting out a faulty airplane that crashes, brings with it lawsuits, damages from victims, huge hikes in insurance premiums, and higher demand from consumers for your competitors' models.
These are very different levels of risk. Of course they are approached differently.
Just because you've never been adversely affected doesn't mean other people's lives aren't ruined.
What about people who have unsavory things leaked about them? (Gay people still in the closet from their ultra-conservative families? Religious people who leave their faith?) What about people who are blackmailed? What about women's private nude pictures? I think they care whether their accounts are compromised.
We have privacy for a reason. It's valuable. And the more we depend on the internet for our lives, placing our private actions (nudity, conversations with our closest friends and family) onto the internet, the more valuable it is to hack and breach it. The more our society values witchhunts, the more valuable it is to breach security to find new savory details to feed those witchhunts.
Imagine if you took an innocent photo of your toddler, naked, in the bathtub. And then found out it was being traded on a pedo ring. You'd feel pretty violated. And then you found out your home address and your child's school address was posted online there. You'd feel pretty scared at that point.
I think the difference is they're extensions of laws for more egregious things like; things that electrocute you, things that give you cancer, or things that explode. (I'm sure another factor is that physical things have been sold for much longer than digital things) Since digital things don't have those catastrophic examples, the other violations don't have the same protections.
http://articles.latimes.com/1999/oct/01/news/mn-17288
The ExoMars mission apparently had a software bug that crashed the lander.
https://www.forbes.com/sites/bridaineparnell/2016/10/26/soft...
As a purely digital artifact, it is highly malleable. Yet its deeply abstract nature, and the complexity enabled by those abstractions, make software very difficult to inspect and understand, compared with the vast majority of things humans make.
Organisations often fail to realise the strategic importance of big IT projects, and fail to treat them accordingly. "The geeks" are tasked with figuring it out.
Whenever a new subway line is built in a city, years and years are spent moving existing underground infrastructure like sewers, water, gas and electricity. All sorts of weird complexity tends to bubble up around this time. A comparable IT project will typically have requirement 264/B-4: The project will be delivered without changing existing infrastructure.
This again probably has something to do with the sequestration of IT as a staff function. This is absolutely the correct place for the office that builds and supports workstations, runs the Exchange server and manages the Active Directory, but it is not where you anchor a large, strategically important project (IT is definitely an important stakeholder, but they don't own it). Emirates doesn't have a staff office tasked with buying, taking delivery and integration the A380 into the fleet, that is a project that spans the organisation and is run out of the CEOs office.
Tangentially to this, there are the complications around the fact that many large IT projects replace existing systems, sometimes decades old. I'm not sure there really is a good physical analogy to the ways old IT systems creep into and get entrenched in adjacent use cases, often without the system owners really realising. It's like Emirates realising two weeks before the inaugural flight of the A380 that there is something about the ailerons of the new plane that means half of the check-in staff can't get to work.
Any aviation or civil engineering project is in a highly regulated environment, and lives can be spectacularly lost if the product fails.
Lawsuits and criminal charges would likely be large and numerous if such a project failed, and was built with entirely new processes and technologies that were seemingly chosen on the whim of a project leader and their people, combined with "something we found on github." (I'm guessing there's no such thing as github for civil or aerospace engineering.)
If your environment constrains you in some dimension, then you're not going to spend much time and resources discovering new ways to stretch that dimension.
"Cherish your constraints," if you will.
Companies that bid, also have twisted priorities, the people who do the bidding, aren't the people that have anything to do with the project, they more onto the next bid.
In my experience some or all of the following will happen on big software projects...
The sales team will bid unrealistically to get the contract, either by underestimating development time or by bidding too low. They will also ignore the advice of experienced devs an PMs when planning their bid.
On winning the bid there will be a ruthless focus on doing things as cheaply as possible. A PM with no experience of this type of project will be put in charge. The rest of the team will largely be chosen based on availability rather than skills or experience. The positions of software architect or technical lead will be seen as optional.
Whatever PM methodology is chosen (probably Scrum), no one will really understand the finer details of how it works. Work will be divvied up poorly, e.g. tasks that need two people working on it together will be given to one person and vice versa.
There will be no thought given to training. Devs will arrive in to find out they are working on some hyper complex financial system, but they will never be given training on what that system is for or how it works.
Inevitably the specs as defined in the bid document will be discovered to be incomplete or faulty. No one will want to actually change the specs, but somehow the devs will be expected to just deal with it.
If the contract is time and materials based as opposed to fixed price then the contractor will massively over-resource the project meaning you end up with a too many cooks situation.
The client will get wind that there are problems and raise concerns. The PMs and hgh-ups in the contracting firm will claim everything is Okay and demand devs work overtime to get things right. They may also utilize smoke and mirrors to fool the client.
As stress builds among the PMs they will start to micro-manage, this will alienate senior devs who know they don't need to take that and they may leave for pastures new. Junior devs will carry on despite still not having the required skills or experience. New devs will be hired, only to leave soon after when they realise that the place is in a mess.
Eventually the project will be delivered late and full of bugs, yet somehow the contractor firm will claim everything went great and organise a piss-up to celebrate.
Just one point regarding this: "The sales team will bid unrealistically to get the contract" - this happens also a lot in construction industry.
This can be broken into three levels of hierarchy.
The executive level is the level VP and above - they write checks. If you don't spend the company's money - you are not at this level. They spend money on programs. They don't know or need to know (or care about) specifics. They are only concerned with the investment and not even individual investments but the organization as a whole.
The bottom level is the IT worker. They are the programmers, managers, etc.. that carry out the specific tasks, do the work.
In between is the (often called Sr. Managers, Acct execs, or VPs in consulting). Not straight sales guys (which is a specific skill, and who are specifically there to close, that's a different breed).
These are the schmoozers. Project people (level 3) have to report to them and they typically hold pretty decent amount of power (reporting to the CEO of a smaller IT consulting or svcs firm, or a COO or SVP in a larger firm). They get credit, sometimes deserved, for bringing in business, so they have power - AND they are often completely incompetent in knowing what to look for and managing a project to success.
They have the power and they don't know what to do, or won't do it. The managers below them, experienced team leads, etc.. know what to do but don't have the power or resources under their control.
It fails at this level, and the level 3 folks (proj mangers, leads, dev, etc..) are not directed appropriately. They may be the greatest team leads and developers etc.. in the world, and the project still fails.