7 ms·

Every time I see engineering projects like this semi-submersible, where massive teams work multiple years to deliver a highly complex project that has never bee

Every time I see engineering projects like this semi-submersible, where massive teams work multiple years to deliver a highly complex project that has never been built before, I feel that the field of software engineering is immature and mostly a joke. If every IT project with an equivalent number of man hours as this ship would produce a physical artifact like this, the sea would be full with abandoned Frankenstein ships, and not a many would actually function. I’m glad that software is invisible, mostly.

mrarjen 7y ago
Likely in some way also to do with the amount of moving parts and it's complexity, not saying the dry dock is simple, but compared to many "invisible" and prone to break parts due to dependence on one another, code can be quite harsh. When one section of the dock doesn't work it won't suddenly flip upside down as could be the case for code.
- Neil44 7y ago
  I found your choice of words quite amusing because the dock really could simply flip upside down!
  - mrarjen 7y ago
    Would be fun to calculate what is required for the dock to actually flip, the scale of it is huge, so you would see it coming a mile away no?
    - Neil44 7y ago
      I’m thinking you would see it coming a mile away, but could you pump water quickly enough to stop it once the centre of gravity got away from you?
- pjc50 7y ago
  > suddenly flip upside down https://catless.ncl.ac.uk/Risks/3.44.html https://catless.ncl.ac.uk/Risks/3.44.html (1986): early F-16 software would flip the plane upside down on crossing the equator :)
  - mrarjen 7y ago
    Thanks for that! Now I'll have sweaty palms going past the equator in airplanes.
    - pjc50 7y ago
      It's good for everyone in their career to read some of RISKS. Reduces your chance of writing a self-driving car that doesn't see pedestrians. And many of the reports have an entertaining style to them. But if you inhale too much of it you'll want to go live in a computerless cabin in a computerless wood.
  - exikyut 7y ago
    Wh..oa. From the above page: > From Dagens Nyheter [Stockholm], Aug. 22, 1986. My translation, abridged. > The chairman of the governmental data- and public-access committee [offentlighetskommitt'en], Carl Axel Petri, rejects the criticisms which have recently been brought by the moderate party [conservative] and folk-party [liberal conservative] concerning sales of personal information from computer data banks. > "It is important to quickly get a law that stops general sales. We have allowed some exceptions, nine specified computer companies, but even their sales shall, in the future, be controlled by parliament. Nobody should be allowed to earn money by [selling] personal information. Sales should have a public interest, in principle, the new law will forbid sales" said Petri. ... I'm removing a bit of context from the above, but it's nice/interesting that this was being discussed in this way back then. Ha.
    - pjc50 7y ago
      Yup, it's not a new idea: http://www.legislation.gov.uk/ukpga/1984/35/contents/enacted http://www.legislation.gov.uk/ukpga/1984/35/contents/enacted .. dating back to 1984, when access would have been over 300 baud modems. The fact that this was largely ineffective against giant US multinationals that didn't respect local law is what lead to the giant international reach of GDPR.
Iv 7y ago
I oscillate between that feeling and the realization that in software, you usually stay on a layer without never really minding the numerous layers under yours, that work flawlessly despite huge complexity. Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other.
- sjwright 7y ago
  > Transistors don't misfire, CPUs don't miss an operation (And if they do, that's usually solved by procurement, warranty or is otherwise someone else's problem.)
- cm2187 7y ago
  And all this wonder of technology ruined because a “developper” built a SQL injection vulnerability in the script that runs at the very top!
- SmellyGeekBoy 7y ago
  > Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other. I don't get it. Is this supposed to be sarcasm?
  - rpmisms 7y ago
    I think it's just a slightly optimistic view of reality.
- jmts 7y ago
  As an embedded software engineer, my only response to this is that sometimes I'm surprised anything works at all. Bugs in silicon do exist. Often there's nothing a supplier can do about it. Either you find a different part or find a workaround at a higher level.
deleted 7y ago
[deleted]
neuronic 7y ago
> I’m glad that software is invisible, mostly But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes. When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.
- jiofih 7y ago
  > Every nut has a checkbox, but code lines don't. That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
  - icebraining 7y ago
    > Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
    - viklove 7y ago
      It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it. This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.
darkwater 7y ago
Well, that's true for the most common "vertical software" most developers create but it's not true for the inner parts like the kernel, system libraries etc, nor for the firmware or the hardware. That ship is a wonderful piece of engineering but so it is the smartphone you have in your pocket! And to go on, software "at scale" like Google's, Facebook's etc, keeping in mind only the technical merit, is just as awesome as that ship if you think about it. For example, searching billions of documents in just a fraction of a second, wherever you are and by millions of people at the same time, isn't a wonderful piece of engineering too?
mywacaday 7y ago
Came to say the same thing, my only hope is that IT/Software is relatively immature compared to traditional engineering.
- LandR 7y ago
  One thing is most of the people that worked on the gnarly parts of these large ships will have a decent engineering education behind them that teaches them the foundations. This is missing in a lot of software developers nowadays, and we as an industry, don't really see the problem with this... I see people applying for jobs with 8 weeks education in a bootcamp and think they should get a job as a software developer... This is normal, and we are ok with this? Rather than making our education faculties for computer students more rigorous it seems we are infantilising them. Garbage in, garbage out. I don't see a path our industry getting better or more mature, if anything I reckon it's going to get way worse before it gets better.
  - rpmisms 7y ago
    I'm a self-taught dev with a few years under my belt, but I got to apprentice as a dev to get to a hireable position. I firmly believe apprenticeship is the solution. Software engineering is constantly evolving, so pair up a junior with a senior who knows how to /think/, and go from there
  - fennecfoxen 7y ago
    You don't need a Rigorous Engineering Background™ to make a cute little website for every mom-and-pop business who needs something a little custom. You need to quickly assemble some off-the-shelf components that work well and probably won't collapse, because the alternative is that they cannot afford anything. The 8-week-bootcamp graduate is not going out and working for Boeing, MCAS memes notwithstanding.
sandworm101 7y ago
But are you seeing the thousands of flaws? These physical projects dont go perfectly. A new cruise ship will have thousands of things wrong with it initially, so too with large lifting ops. Just because the massive thing moves doesnt mean the enineering was seemless. Thr skill is in accepting and working around inevitable flaws, unknown unknowns, in a manner not very different than software.
wodenokoto 7y ago
The current top comment mentions that the OTHER ship needs all bearings replaced after only 3 years, due to some major manufactoring fault. So it is not only software that produce faulty products.
gonzo41 7y ago
software isn't steel. It's more complex. Think about everything that went into you posting that message. OSI stack 1-7, your computer or phone. Keyboard, the browser you used. The php / database on ycombinator. There's lots of successful software. And there are pleanty of bad ships that blow out budgets.
vsareto 7y ago
The consumer-grade industry moves too quickly to produce stuff like this. There are still mainframes running, after all.
- criddell 7y ago
  All the software I use on a daily basis is pretty much good enough. I'd be thrilled if everybody decided to freeze development of new features and instead dedicate all their resources to fixing bugs for a few years.
C1sc0cat 7y ago
Which actually happened in the late 19th century ships where laid down and where obsolete within 2 or 3 years. In some cases the ship was laid down and was obsolete when launched. An for Fankenships take a look at French pre dreadnaughts - "when hotels go to war" as some on YouTube put it
phkahler 7y ago
I'm sure a lot of software was used in the design and production of the ship. CAD, FEA, CFD, and then all the logistics, and financial planning... Iteration happens in mechanical designs too, but a lot of that is done virtually before physical parts are made. In software there is no distinction between virtual code and real code. We make a somewhat artificial distinction by having official releases that have hopefully gone through more testing.
mattlondon 7y ago
I have to remind myself that in "real" engineering there are (in theory) no surprises for the well understood physical processes at work. There is never a new and immature "gravity library" that requires you to rework your existing designs to cope for new slightly different acceleration due to gravity, the "metal fatigue" library does not introduce new unexpected bugs randomly, there is no reason for the "corrosion library" not being able to be used at the same time as the "average human adult male height library" due to obscure dependency issues, you never have shoe-horn in the "compressive strength of concrete" functionality that was originally out of scope but sales now say is P0, you never have bugs like unexpected-yet-sufficiently loud sound waves overflowing to tiny negative values etc and causing a "negative sound area" or something weird and hard to conceptualise. I.e. physics itself is largely unchanging. We have worked out the fundamentals and they don't really change - gravity never flips direction, bounancy always goes "up" etc - and we're not building on top of a ship that is built on top of another ship that is built on top of a hovercraft that is built in top of raft that is built on logs that is built for a fresh water environment but you are using it in salt water due to the CEO being buddies with someone, but the people building the ship only see the first turtle beneath them.
- fennecfoxen 7y ago
  Oh, but there's new libraries out there: less in the physics (which remain as fundamental as the unchanging principles of computer science and mathematics) and more in the applications. For instance, right now I type this I am sitting in what is, last I checked, the tallest modular building in the world: parts assembled at factory offsite, and trucked in by crane. In other construction techniques, we can see things like 3-D printing, in variants that range from "extruding concrete in boring square shapes on the foundation" to "laser-sintering alloys into exciting new organic designs". There are exciting new materials, as well; would you consider building with cross-laminated timber? Would you build a plane with carbon fiber? Okay, how about one with a maneuvering characteristics augmentation system? (POSTSCRIPT: Just checked, not the tallest anymore.)
  - GFischer 7y ago
    Was about to ask you if HN wasn't blocked in China :) . I guess you're in London then.
mapt 7y ago
We have a model for a fully mature mission-critical software development process. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
Gravityloss 7y ago
The ship is a lot simpler by many measures than something like Linux. In software the experimentation cost is very small so it makes sense that there are a lot more prototypes and abandoned projects etc.
tomatotomato37 7y ago
Don't forget the whole reason the heavy lift ship was being used was because of badly designed bearings on this cruise ship's azimuth thrusters combined with the local drydock being out of commission because of two cranes collapsing on another cruise ship undergoing repairs at the time. So in just this story we have a maintenance failure (bearings) and two critical failure (cranes) in physical engineering.
- jhayward 7y ago
  > So in just this story we have a maintenance failure (bearings) They are replacing the bearings on all the azipods, which tells us this is a design and engineering failure rather than a maintenance failure.
golergka 7y ago
If every IT project was developed as ships and buildings are, we would celebrate the release of the first spreadsheet application and whatever was the most basic predecessor to ARPAnet about now. Different projects have different priorities. If my app crashes, no one's going to die, but if I'll waste time on formal verification of my database layer, quite a few people will end up losing their jobs and/or investments.
s3ct01d 7y ago
Even without considering the recent advancements in areas like autonomous marine systems or fuel consumption optimization, the amount of software required to even get ships like that of the dock is insane.
JoeAltmaier 7y ago
Mechanical engineering projects have thousands of parts. About equivalent to a chip with a shift register and a serial port. Or a piece of software with a small array of integer variables and a loop, compiled to assembly language. Not so say they aren't challenging. But software is billions of parts, and its freaking incredible we can get anything to work at all.
spyder 7y ago
Huh... most of them has been built by using complex software and a lot of them is using software too work. Webdev != all software engineering.

mrarjen 7y ago

Likely in some way also to do with the amount of moving parts and it's complexity, not saying the dry dock is simple, but compared to many "invisible" and prone to break parts due to dependence on one another, code can be quite harsh. When one section of the dock doesn't work it won't suddenly flip upside down as could be the case for code.

Neil44 7y ago
I found your choice of words quite amusing because the dock really could simply flip upside down!
- mrarjen 7y ago
  Would be fun to calculate what is required for the dock to actually flip, the scale of it is huge, so you would see it coming a mile away no?
  - Neil44 7y ago
    I’m thinking you would see it coming a mile away, but could you pump water quickly enough to stop it once the centre of gravity got away from you?
pjc50 7y ago
> suddenly flip upside down https://catless.ncl.ac.uk/Risks/3.44.html https://catless.ncl.ac.uk/Risks/3.44.html (1986): early F-16 software would flip the plane upside down on crossing the equator :)
- mrarjen 7y ago
  Thanks for that! Now I'll have sweaty palms going past the equator in airplanes.
  - pjc50 7y ago
    It's good for everyone in their career to read some of RISKS. Reduces your chance of writing a self-driving car that doesn't see pedestrians. And many of the reports have an entertaining style to them. But if you inhale too much of it you'll want to go live in a computerless cabin in a computerless wood.
- exikyut 7y ago
  Wh..oa. From the above page: > From Dagens Nyheter [Stockholm], Aug. 22, 1986. My translation, abridged. > The chairman of the governmental data- and public-access committee [offentlighetskommitt'en], Carl Axel Petri, rejects the criticisms which have recently been brought by the moderate party [conservative] and folk-party [liberal conservative] concerning sales of personal information from computer data banks. > "It is important to quickly get a law that stops general sales. We have allowed some exceptions, nine specified computer companies, but even their sales shall, in the future, be controlled by parliament. Nobody should be allowed to earn money by [selling] personal information. Sales should have a public interest, in principle, the new law will forbid sales" said Petri. ... I'm removing a bit of context from the above, but it's nice/interesting that this was being discussed in this way back then. Ha.
  - pjc50 7y ago
    Yup, it's not a new idea: http://www.legislation.gov.uk/ukpga/1984/35/contents/enacted http://www.legislation.gov.uk/ukpga/1984/35/contents/enacted .. dating back to 1984, when access would have been over 300 baud modems. The fact that this was largely ineffective against giant US multinationals that didn't respect local law is what lead to the giant international reach of GDPR.

Iv 7y ago

I oscillate between that feeling and the realization that in software, you usually stay on a layer without never really minding the numerous layers under yours, that work flawlessly despite huge complexity. Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other.

sjwright 7y ago
> Transistors don't misfire, CPUs don't miss an operation (And if they do, that's usually solved by procurement, warranty or is otherwise someone else's problem.)
cm2187 7y ago
And all this wonder of technology ruined because a “developper” built a SQL injection vulnerability in the script that runs at the very top!
SmellyGeekBoy 7y ago
> Transistors don't misfire, CPUs don't miss an operation, firmware invisibly and reliably handle all the internal packets of the motherboard, the screen refreshes millions of pixels every 16 ms. All of this relies on the work of thousands if not millions of people who have never meet each other but whose piece of work communicate flawlessly with each other. I don't get it. Is this supposed to be sarcasm?
- rpmisms 7y ago
  I think it's just a slightly optimistic view of reality.
jmts 7y ago
As an embedded software engineer, my only response to this is that sometimes I'm surprised anything works at all. Bugs in silicon do exist. Often there's nothing a supplier can do about it. Either you find a different part or find a workaround at a higher level.

deleted 7y ago

[deleted]

neuronic 7y ago

> I’m glad that software is invisible, mostly But that also makes it somewhat intangible and the ability to analyze, test and observe a large software construct relies on the mental capacity to read and grasp units of code and its complex interactions. Once components start messaging with each other and cross-influence their state you quickly enter the realm of complexity theory and tight control of information flow is the only way to guarantee some degree of predictable outcomes. When I see these ship assembly videos, it's very tough engineering and often novel territory but you got something in your hands, you see the parts move and can measure their forces and evaluate interactions. Every nut has a checkbox, but code lines don't.

jiofih 7y ago
> Every nut has a checkbox, but code lines don't. That’s part of the problem. Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it. This is more about the process of development than the artifacts.
- icebraining 7y ago
  > Usually the output and behavior of a program is well specified enough that we should have a checkbox (test?) for it I've literally never worked in a project like this. It's always "here's some general idea of what we want, with a couple of hard constraints. Build it however it makes sense to you, and we'll change anything we don't like after we see it." The only exception I can think of is data import from a known file format or API.
  - viklove 7y ago
    It's very easy to explain to someone why blowing a hole in their bedroom wall to put an extension cord through it is a bad idea. On the other hand, try explaining to your product team that building a certain feature in 2 weeks will require doing the equivalent of that, and they won't see any issues with it. This is the problem with building software. It's intangible and non-developers have a very hard time understanding the tradeoff of doing something "hacky" vs doing it right.

darkwater 7y ago

Well, that's true for the most common "vertical software" most developers create but it's not true for the inner parts like the kernel, system libraries etc, nor for the firmware or the hardware. That ship is a wonderful piece of engineering but so it is the smartphone you have in your pocket! And to go on, software "at scale" like Google's, Facebook's etc, keeping in mind only the technical merit, is just as awesome as that ship if you think about it. For example, searching billions of documents in just a fraction of a second, wherever you are and by millions of people at the same time, isn't a wonderful piece of engineering too?

mywacaday 7y ago

Came to say the same thing, my only hope is that IT/Software is relatively immature compared to traditional engineering.

LandR 7y ago
One thing is most of the people that worked on the gnarly parts of these large ships will have a decent engineering education behind them that teaches them the foundations. This is missing in a lot of software developers nowadays, and we as an industry, don't really see the problem with this... I see people applying for jobs with 8 weeks education in a bootcamp and think they should get a job as a software developer... This is normal, and we are ok with this? Rather than making our education faculties for computer students more rigorous it seems we are infantilising them. Garbage in, garbage out. I don't see a path our industry getting better or more mature, if anything I reckon it's going to get way worse before it gets better.
- rpmisms 7y ago
  I'm a self-taught dev with a few years under my belt, but I got to apprentice as a dev to get to a hireable position. I firmly believe apprenticeship is the solution. Software engineering is constantly evolving, so pair up a junior with a senior who knows how to /think/, and go from there
- fennecfoxen 7y ago
  You don't need a Rigorous Engineering Background™ to make a cute little website for every mom-and-pop business who needs something a little custom. You need to quickly assemble some off-the-shelf components that work well and probably won't collapse, because the alternative is that they cannot afford anything. The 8-week-bootcamp graduate is not going out and working for Boeing, MCAS memes notwithstanding.

sandworm101 7y ago

But are you seeing the thousands of flaws? These physical projects dont go perfectly. A new cruise ship will have thousands of things wrong with it initially, so too with large lifting ops. Just because the massive thing moves doesnt mean the enineering was seemless. Thr skill is in accepting and working around inevitable flaws, unknown unknowns, in a manner not very different than software.

wodenokoto 7y ago

The current top comment mentions that the OTHER ship needs all bearings replaced after only 3 years, due to some major manufactoring fault. So it is not only software that produce faulty products.

gonzo41 7y ago

software isn't steel. It's more complex. Think about everything that went into you posting that message. OSI stack 1-7, your computer or phone. Keyboard, the browser you used. The php / database on ycombinator. There's lots of successful software. And there are pleanty of bad ships that blow out budgets.

vsareto 7y ago

The consumer-grade industry moves too quickly to produce stuff like this. There are still mainframes running, after all.

criddell 7y ago
All the software I use on a daily basis is pretty much good enough. I'd be thrilled if everybody decided to freeze development of new features and instead dedicate all their resources to fixing bugs for a few years.

C1sc0cat 7y ago

Which actually happened in the late 19th century ships where laid down and where obsolete within 2 or 3 years. In some cases the ship was laid down and was obsolete when launched. An for Fankenships take a look at French pre dreadnaughts - "when hotels go to war" as some on YouTube put it

phkahler 7y ago

I'm sure a lot of software was used in the design and production of the ship. CAD, FEA, CFD, and then all the logistics, and financial planning... Iteration happens in mechanical designs too, but a lot of that is done virtually before physical parts are made. In software there is no distinction between virtual code and real code. We make a somewhat artificial distinction by having official releases that have hopefully gone through more testing.

mattlondon 7y ago

I have to remind myself that in "real" engineering there are (in theory) no surprises for the well understood physical processes at work. There is never a new and immature "gravity library" that requires you to rework your existing designs to cope for new slightly different acceleration due to gravity, the "metal fatigue" library does not introduce new unexpected bugs randomly, there is no reason for the "corrosion library" not being able to be used at the same time as the "average human adult male height library" due to obscure dependency issues, you never have shoe-horn in the "compressive strength of concrete" functionality that was originally out of scope but sales now say is P0, you never have bugs like unexpected-yet-sufficiently loud sound waves overflowing to tiny negative values etc and causing a "negative sound area" or something weird and hard to conceptualise. I.e. physics itself is largely unchanging. We have worked out the fundamentals and they don't really change - gravity never flips direction, bounancy always goes "up" etc - and we're not building on top of a ship that is built on top of another ship that is built on top of a hovercraft that is built in top of raft that is built on logs that is built for a fresh water environment but you are using it in salt water due to the CEO being buddies with someone, but the people building the ship only see the first turtle beneath them.

fennecfoxen 7y ago
Oh, but there's new libraries out there: less in the physics (which remain as fundamental as the unchanging principles of computer science and mathematics) and more in the applications. For instance, right now I type this I am sitting in what is, last I checked, the tallest modular building in the world: parts assembled at factory offsite, and trucked in by crane. In other construction techniques, we can see things like 3-D printing, in variants that range from "extruding concrete in boring square shapes on the foundation" to "laser-sintering alloys into exciting new organic designs". There are exciting new materials, as well; would you consider building with cross-laminated timber? Would you build a plane with carbon fiber? Okay, how about one with a maneuvering characteristics augmentation system? (POSTSCRIPT: Just checked, not the tallest anymore.)
- GFischer 7y ago
  Was about to ask you if HN wasn't blocked in China :) . I guess you're in London then.

mapt 7y ago

We have a model for a fully mature mission-critical software development process. https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff

Gravityloss 7y ago

The ship is a lot simpler by many measures than something like Linux. In software the experimentation cost is very small so it makes sense that there are a lot more prototypes and abandoned projects etc.

tomatotomato37 7y ago

Don't forget the whole reason the heavy lift ship was being used was because of badly designed bearings on this cruise ship's azimuth thrusters combined with the local drydock being out of commission because of two cranes collapsing on another cruise ship undergoing repairs at the time. So in just this story we have a maintenance failure (bearings) and two critical failure (cranes) in physical engineering.

jhayward 7y ago
> So in just this story we have a maintenance failure (bearings) They are replacing the bearings on all the azipods, which tells us this is a design and engineering failure rather than a maintenance failure.

golergka 7y ago

If every IT project was developed as ships and buildings are, we would celebrate the release of the first spreadsheet application and whatever was the most basic predecessor to ARPAnet about now. Different projects have different priorities. If my app crashes, no one's going to die, but if I'll waste time on formal verification of my database layer, quite a few people will end up losing their jobs and/or investments.

s3ct01d 7y ago

Even without considering the recent advancements in areas like autonomous marine systems or fuel consumption optimization, the amount of software required to even get ships like that of the dock is insane.

JoeAltmaier 7y ago

Mechanical engineering projects have thousands of parts. About equivalent to a chip with a shift register and a serial port. Or a piece of software with a small array of integer variables and a loop, compiled to assembly language. Not so say they aren't challenging. But software is billions of parts, and its freaking incredible we can get anything to work at all.

spyder 7y ago

Huh... most of them has been built by using complex software and a lot of them is using software too work. Webdev != all software engineering.