No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to guide the ship and check the weather, operators from all around the world to track the containers, massive ports to load-unload the shipments, etc...
The operation of guiding the containership through the sea is a simple one but only once you have everything of the mentioned above in order.
If you are building software (a full SaaS solution), you are not in the business of guiding the containership. You are in the business of building either the containership alone; or the whole related infrastructure (or parts of it). That's a huge undertaking that requires massive engineering efforts. It's not a simple task.
If your task is a simple team that guide the container, you might make money for a while until everyone else figures out that you have no edge there and they can do your job for much less.
The Instagram/Tinder examples are a bad one. It ignores the fact that to find the right (addictive/highly viral) app, you'll need (again) massive psychological knowledge and expertise into how primates brains work. We don't have that, so engineers are brute-forcing by making too many apps until one hits the jackpot.
My point is that simple-to-understand systems--not simple as in primitive--have less downtime, not that we shouldn't ever have complex systems. A container ship like the one in my article can be drydocked ("in the shop") for repairs and back on the water in less than two weeks. A nuclear-powered aircraft carrier cannot. So be mindful when you're building an aircraft carrier when a container ship would've sufficed.
By the way, most of the "complex" stuff in the photo--which isn't a container ship--is scaffolding and piping.
Source: Got a naval architecture degree and a marine engineering license, operated a steamship for six months at sea, and designed ships for the US Navy for three years before abandoning ship to work with startups.
An interesting thing to contrast that with is the Boeing disaster. Where they decided to make the steering actually more complex, then hide it from the pilot with software to make it look like the old, simple thing.
The result was a system that worked fine until you encountered bugs in the software, at which point there was no helping that several hundred people were about to die.
sure nuclear carriers cannot be dry docked and serviced like a container ship but they can be deployed for long periods of time without refueling and other routine services.
My point here is that the way you measure reliability is subjective and there are likely trade offs associated with “simplicity”
For example, having a global signal point of failure, like keeping all of your api servers in one cloud region, or having a single database with no replicas is much simpler and easy to understand than a more distributed alternative. However, global resources make your system more likely to fail catastrophically when there are outages.
There are trade offs here and _oftentimes_ in complexity arises in distributed systems because of reliability issues, not the other way around
Did you actually read the article? He makes it quite clear why the lesson of simplicity applies to a container ship. Analogy is not homology. Just because container ships are part of a complex system does not mean that the steering system isn't valuably simple compared with other alternatives. And it definitely doesn't mean we can't learn a lesson from that.
Also, I think this is straight up wrong:
> If you are building software (a full SaaS solution), [...] That's a huge undertaking that requires massive engineering efforts. It's not a simple task.
If you believe it will require "massive" engineering efforts, you will certainly prove yourself right. But quite a lot of people do it differently. Look at Amazon's rule about two-pizza teams, for example. Or just this week I visited a ~30-person company that's been going 8 years with a successful SaaS business. They have a team of 4 developers, and it works just fine because they work to keep things simple.
One of the first line of the article states that he is a formal Naval Architect. That is to say he literally built ships. I would imagine he has some idea of the complexities involved, but still found it to be a useful anology.
Postulating about how things should be by non-experts has become a new e-sport. Then they try to apply it to software or startups as if its a apples to apples comparison.
In general, arguments by analogy tend to get hung up on the aptness of the analogy. I find it helps short-circuit a lot of long, unproductive discussions at work by just straightforwardly stating my thoughts—“we should do x because y,” rather than “system A is like system B (which does x because y), so we should do x.”
As the author points out in the sibling comment, that's not a containership. It's an FPSO on top of a heavy-lift ship. An FPSO is basically a floating oil refinery, which is what the maze of piping and equipment is for. AFAIA, the vessel itself has no propulsion (which is why it's on top of the heavy-lift ship) and is just a large floating tub—You can't get much simpler than that.
The author was not talking about software engineer but the user of software (sales & marketing).
Building Hubspot (the example in his article) is a complex task. But implementing it in your business process should be a redundant and straightforward one.
Warehouse/Workshop Model is more simple, the large industrial assembly line is the mainstream production technology in the world.
But simplicity does not mean easy. It is actually systematic engineering. It is difficult to design a complex system into a simple and smooth Warehouse(database, pool)/Workshop(pipeline) Model system.
Is there any way I could convince you to stop clogging up the internet pipes with comments that seem to solely focus on 'pipes' and 'warehouses'? Surely there are other things that you care about and could contribute to HN?
No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to guide the ship and check the weather, operators from all around the world to track the containers, massive ports to load-unload the shipments, etc...
The operation of guiding the containership through the sea is a simple one but only once you have everything of the mentioned above in order.
If you are building software (a full SaaS solution), you are not in the business of guiding the containership. You are in the business of building either the containership alone; or the whole related infrastructure (or parts of it). That's a huge undertaking that requires massive engineering efforts. It's not a simple task.
If your task is a simple team that guide the container, you might make money for a while until everyone else figures out that you have no edge there and they can do your job for much less.
The Instagram/Tinder examples are a bad one. It ignores the fact that to find the right (addictive/highly viral) app, you'll need (again) massive psychological knowledge and expertise into how primates brains work. We don't have that, so engineers are brute-forcing by making too many apps until one hits the jackpot.