
Why can't the IT industry deliver large, faultless projects quickly? - Garbage
https://softwareengineering.stackexchange.com/questions/158640/why-cant-the-it-industry-deliver-large-faultless-projects-quickly-as-in-other
======
AriaMinaei
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.

~~~
godelmachine
A small bug in software that was used in Challenger brought down the entire
space shuttle, killing all of its crew.

~~~
erik_seaberg
_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?

~~~
pkroll
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.

~~~
erik_seaberg
Ditching the tank might help, but I wonder whether the control surfaces are
quick enough to prevent tumbling in the hypersonic airstream.

------
tofflos
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.

~~~
zerd
Funny that they mention the A380 specifically because it was actually finished
several years behind plan and billions of dollars above budget.

[http://calleam.com/WTPF/?p=4700](http://calleam.com/WTPF/?p=4700)

~~~
tofflos
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. ;-)

------
d--b
My view is that the single most important cause for this effect is the low
cost of failing: Because software is immaterial, the cost of a fault is
usually fairly small (in that it's rare that a bug breaks physical things),
and the cost of fixing is also small. It happened to all of us: you ship a
bug, someone notices it, you fix it, you ship an update, and it's done.

In other engineering disciplines, failing is often life-threatening and the
cost of fixing the problem can skyrocket pretty fast.

So, in IT, faultlessness does not weigh very much against time-to-market or
development costs.

In projects were IT faults could be lifethreatening, you generally see much
higher quality standards

------
kyriakos
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.

~~~
lightedman
"On the other hand airplanes are designed tested in small scale for proof of
concept and specs are finalised before any production work begins."

Let me introduce you to the F-35 and let's see how you react to that.

~~~
kyriakos
This actually proves my point that having a solid spec also means a quicker
project completion.

~~~
Too
Writing a solid spec isn't free either. You spend 5 years on writing a spec
and 1 year implementing, instead of the other way around.

------
DoubleGlazing
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.

~~~
jakub_g
Great writeup!

Just one point regarding this: "The sales team will bid unrealistically to get
the contract" \- this happens also a lot in construction industry.

------
temporallobe
In my experience it has been due to several glaringly obvious oversights and
blunders.

1) Not empowering developers by blocking access to critical resources,
basically walling them off in a tightly-controlled box and still expecting
them to do their jobs because "they should be able to figure it out".
Ridiculous shit like no admin rights, strict enforcement of specific
tools,etc. This is usually due to an IT or security department with a
inflexi,no fucks given, block everything attitude.

2) Not hiring a strong architect who has the vision for project and the power
to make major decisions. So many organizations don't think this is necessary
and often have someone in management play this role.

3) Having a weak management team that won't stand up to the customer to tell
them what can and can't be done, and not letting them dictate how to do
technical things.

4) Skipping or not enforcing basic well-established engineering practices such
as design, testing, peer review, etc.

5) Using ill-advised "solutions" platforms that are not intended for engineers
but for business analysts with some tech background. These platforms are sold
to government and enterprise by used-car-salesmen-like sleazy marketing
departments that straight up lie about capabilities or omit huge faults or
inabilies. Stupid and/or tech-ignorant management buys this shit and it's
crappy, expensive licenses for years to come. They can't get rid of it because
of sunken costs, etc.

6) Fear of anything open source

7) Inability to find good, reliable talent -- anything from engineers to
testers to tech writers (and who actually have good English skills). Many,
many people I work with are great engineers but have such poor English skills
that I literally can't understand a thing they're saying, even in an email.

8) Management or stakeholders straight up not giving a shit and letting the
project die due to personal problems, infighting, interpersonal issues,
corruption, etc. This I would say is the most important issue.

~~~
Joeri
9) Letting the sales guys write the spec, in the form of a powerpoint.

10) taking estimates from development and lopping off a big chunk plus adding
extra scope, because “I couldn’t sell the original estimate” and “this project
will be a great reference, so we can take the hit”

11) doing _agile_ in the sense of changing scope / direction constantly, but
requiring complete timelines for project delivery to check planned vs actuals.

12) the perennial favorite: having multiple managers who are too busy to talk
to each other but not too busy to give conflicting instructions.

~~~
jakub_g
Most of the points above are very true, particularly 3,5,7,9,10,11 from my
experience.

Additionally:

13) POs and devs accepting feature requests that don't add value but add a lot
of complexity

14) Team members who add negative velocity and lower morale of everyone else
in the project (but typically are highly regarded by the management who
dismiss any complaints)

The core IMO is that most people (especially non-technical, but technical too)
can not properly understand the complexity of a software project as it's not
something tangible like a building or a bridge.

------
mseebach
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.

------
thisisit
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.

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...](https://www.bloomberg.com/news/articles/2016-12-27/airbus-to-
slow-a380-production-in-2017-in-accord-with-emirates)

And the engines the mainstay of a plane have found to be have problems:
[https://www.bloomberg.com/news/articles/2016-11-18/emirates-...](https://www.bloomberg.com/news/articles/2016-11-18/emirates-
says-rolls-royce-a380-engines-not-up-to-agreed-standard)

------
static_noise
One essential part is managing complexity.

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.

~~~
csydas
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.

~~~
panic
Plus you can see the dependencies directly in "real" engineering. In software
it's all completely invisible.

------
mschuster91
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.

------
dwaltrip
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.

------
everdev
I think part of it has to do with complexity. For a roadway, it must be tested
within a specific temperature range and weight range. For software, it's
considered a failure if anything can break it, foreseen or unforeseen.

If roads were tested like software, you could say "yeah, it supports all the
common/pre-defined use cases, but we just found out it's susceptible to a
jackhammer. Better fix that." And then your road would never be finished just
as software is never finished.

------
hopsoft
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.

------
justboxing
...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.

~~~
static_noise
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.

------
sengork
This is the illustrated version of the discussion:

[http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=...](http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=A4)

------
cbames89
Is there a precedent in any field? Large, complex projects seem to inherently
require delays due to the discovery of new facets of the project.

~~~
fpoling
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.

------
dpweb
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.

------
rdtsc
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.

------
fpoling
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.

~~~
jacalata
They do? Can you name some examples?

~~~
fpoling
The very beginning of [1] in the introduction of the speaker gives game
titles.

[1] - [https://youtu.be/rX0ItVEVjHc](https://youtu.be/rX0ItVEVjHc)

~~~
pandaman
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.

------
codingdave
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.

------
us0r
Being late on a software project is actually profitable.

Being late on an aircraft or building probably comes with financial penalties.

~~~
user5994461
The big contracted/outsourced projects usually have equally big penalties
clause in their contracts. It doesn't really help.

------
olavk
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...](https://en.wikipedia.org/wiki/Airbus_A380#Production_and_delivery_delays)
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.

------
rwallace
Because no industry can deliver large, faultless projects quickly. What a
strange question.

------
ImSkeptical
My feeling is that it's easier to tell if you're doing the right thing in some
of these projects - e.g "Yes, we are building a big concrete wall that will
hold back water" etcetera. Also, these projects are undertaken by teams of
professionals who are working in a more or less well understood field.

Conversely, in a software project neither of those things may be true. Imagine
the "reset password" feature. Sure, it reset the password for your test
account. What about a student account created before 2010 (when there was that
big accounts change) with restricted ads, from China, marked for suspicion of
fraud and the account details service is responding slower than usual... plus,
the feature was written by an intern in his second year of a CS degree.

------
vacri
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.

------
a3n
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.

"Cherish your constraints," if you will.

------
blackkettle
According to wikipedia the road from R&D conception to commercial deployment
with Singapore Airlines for the A380 spanned almost 20 years, from 1988 to
2007.

How many software projects have that sort of scope?

------
westiseast
My initial response is that the software industry doesn't actually do projects
of that scale and with that kind of budget very often.

Unless you're working at Google scale, what's the budget for your website
project? $100k? $200k? Departmental budget of $3million a year which is 90%
salaries and 10% hardware?

Generally speaking, those businesses handling airplanes, submarines,
skyscrapers etc are always working at that scale and everyone is prepared for
that.

~~~
AlphaSite
I think part of the problem is that the scale of software far higher than its
price may imply. It’ll last as long as any bridge and may very well serve as
many people, but it’ll cost 1/100 the price.

A bank’s software is an example of this.

------
theduncan
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.

------
kusmi
edge-cases. I feel like edge cases balloon exponentially relative to data
size, where it feels as if at some point you might as well just screw the
automation and handle each entry individually. Who cares, it's never going to
be 'complete' anyway.

------
X86BSD
Complexity. As many others have also listed reasons why, systems today are
made using needlessly complex designs because of a lack of skill and for speed
of deployment.

------
jasonlotito
I wonder if the Airbus A380 would be possible without the software it uses to
operate it?

------
NotUsingLinux
Easy to answer: human nature / society/ economy

------
pdog
Quality. Speed. Price. Pick any two.

------
known
Requirements != Expectations

------
CM30
Well, there are a few reasons. Before I begin though, it's probably best I
mention that every industry has its faults. The difference in a lot of cases
is merely between fixing all the ones normal people would encounter in every
day life and trying in vain to fix everything. You'll never do the latter in a
million years.

But the difference is likely that:

1\. Time frames are quicker in IT fields, especially web development fields.
So corners are cut and things are rushed to get them out the door. Same deal
in games, where publishers assume they can release now and patch later.

2\. There are stricter regulations in other fields. Not surprising cause they
need them, the consequences are higher if things go wrong. Meanwhile IT
projects (especially on a smaller scale/outside the finance industry) can be
summed up as 'if it works, it's good'. Same with game development.

3\. Human attacker risks are lower in many fields. This comes down to two
things:

A: There's less of an incentive to 'test' non IT projects. For IT stuff like
sites, breaking them can mean money from bounties (at the good end) and data
to sell to criminals (on the negative end). For games, it can mean
distributing pirated copies via torrent sites or gaining access to the console
hardware. For an aeroplane or building? Why would anyone need to find faults?
At least outside of internal testing or certification services...

B: It's much easier for them to find faults. They can attack an IT project
without leaving the house, and they obviously have physical/file access to any
games they own. No one has easy access to test buildings or large vehicles.

4\. The risks provide a greater incentive to 'do things right'. If the worst
that can happen is a site crashes/gets hacked, or even that the user finds a
few random small bugs, there's less of an incentive than if the risk is loss
of life or a huge financial loss.

5\. A lack of standardisation or 'best practices'. People know what's good in
vehicle or building design, and most are very much like others of the same
type. Websites are mostly unique from each other, and games are often similar.
There's a lot more uncharted territory there.

6\. Careful planning is more common in some fields than others. A plane or
building is probably not going to be revised very much, especially if there's
no pressing reason to revise it mid development. A website or app may well be
(especially if the client keeps changing them mind), and a game often will be
as well (if something either isn't turning out to be fun, or the management
decide the latest hot idea has been incorporated now). So the time available
for testing and proper development can be limited due to constantly changing
demands.

And yes, I feel the 'managing complexity' aspect brought up by static_noise is
relevant here too. It's easier to figure out what each part of a mechanical
system does than it is to do the same with a computer program or script.
That's why large sandbox type games (like say, Zelda Breath of the Wild) can
get rather buggy if you try unusual things. Because no Q/A team on the planet
can find every odd thing a player could try and get the developers to
implement a logical response to it. No one's going to find stuff like that
which Stryder7X shows in his videos without being either going well out of
their way to try insane things or being shown them:

[https://www.youtube.com/watch?v=XFWjGXmnpno](https://www.youtube.com/watch?v=XFWjGXmnpno)

Either way, there are lots of reasons really.

------
katastic
Speaking as a mechanical engineer:

Another issue is simply encapsulation. You can encapsulate physical problems
to reduce their complexity. A spring is a spring. We "could" use finite-
element-analysis to make a spring that is also a damper, and a lever at the
same time. But it's way more cost-effective and easier to reasonable when we
use discrete components. A spring is a spring. A damper is a damper. You want
both, you put them together.

We "could" create capacitors that are also inductors and resistors. But it's
way easier to reason about them separately.

Like I said, a spring is a spring. It will never set off an atomic explosion.
It will never turn into lead. It will never warp into a living person. You can
reason about that spring and as long as you live within "safe" areas it will
always act the way you expect it. You can easily predict the failure rate of a
given spring for given environment of heat, forces, etc.

Meanwhile, you have an app. You think it's encapsulated. But it's not. Your
app is a network app. That means the router could die or be misconfigured. The
ISP could go down. You could forget to pay the ISP bill. The internet backbone
could go down. And, not only that, it's not just "down" it could simply be
"slower" or have a higher packet loss than normal, or end up sending duplicate
packets.

We spend so much time trying KNOWING that things can fail anywhere along the
line, we "fix" it by adding redundant, fault-tolerant, load balancing systems.
Except each of those systems increase the complexity and can fail in even more
ways!

And I haven't even discussed what the app does yet! And just being connected
to the internet or another network machine and it's already exploded in ways
that it could fail. Even the WIRES in the wall could be corroded, unplugged,
or eaten by a rat. And, if the power goes out anywhere along the chain you
could have problems. If the power "kind of" goes out and you don't have proper
battery backup, it could introduce errors. A Windows Update can (and DOES)
break products all the time. A Java Update can break things. A driver update
can break things. A hard drive failing can subtly break your software. Any
third-party software you use could have a hidden bug. A router could have ONE
and only ONE port, or one cable with a slight kink in it, could have a higher
error rate.

There's a famous story of back-in-the-day when mainframe actually failed at
the same time every day. It failed when people walked over a specific TILE in
the floor where the wires ran under it.

Meanwhile, that spring, sitting on a table in some warehouse will remain a
spring till it rusts away a couple hundred years later. The spring constant
won't change. It won't unravel. It won't leak your boss's e-mails. It'll still
be a spring.

So while yes, there ARE very complex mechanical constructs. However, they're
actually pretty rare because in the physical world "simple" is the most
reliable and often the strongest solution. Meanwhile, in business, you're
dealing with tons of logic and even though you "think" it's encapsulated, it's
actually not.

Summary / TL;DR: Most mechanical machines aren't dealing with the dimensional
explosion of possibilities. They do have failure points just not as many.

(Also, one great thing about many machines is because they're physical, you
can often diagnose many of them before they fail. They vibrate. They create
sound. They output less than they're supposed to. A router doesn't warn you
before it decides to stop forwarding a port.)

~~~
AlphaSite
I think the distinction here is a spring vs an aeroplane, the closest thing to
a spring is probably a float.

~~~
katastic
And how many ways can a float blow up?

NaN. Global state flag registers than destroy multi-threading. Propagation of
errors. Casting errors. etc. And that's just one variable!

------
andrewstuart
Politics.

~~~
static_noise
What aspects of politics?

How do they interact with engineering?

~~~
maxxxxx
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.

~~~
sidlls
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.

