61–70 of 271 posts
Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.
I would really love to read their codebase.
I like the ship analogy from the article. The fact it is so robust is not because the system as a whole is simple, but because its components have well defined, narrow responsibilities and there are abstract interfaces between them, which hide a lot of complexity. You don't need to understand the internals of the pump to explain what it does, even though the actual internal technology may be quite complex and clever.…
A startup is a new destroyer that has been floated, did not have sea trials and went to war with a crew that might have a couple of people that used to a drive container ship but mostly staffed with kids that thought it was cool to play with a destroyer. Oh, and 3/4 of the systems are still at best have been drawn on a napkin and most of the rest came from a salvage yard. Oh and if you complete your next mission you may get money you can spend on some of the systems but if you do get that money you would be expected to do a lot more runs, quicker.
The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…
All those complicated lists? Forth is even further down the path to ultimate minimalism. Really only one data structure, a stack with binary values on it...
Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.
I would really love to read their codebase.
Using the company this author helped to migrate to hubspot as an example. I'm not sure if the simpler solution - hubspot existed when the company started hacking solutions together. Also, the move to hobspot was relatively easy because the business processes and workflows were already well known and defined. Starting from scratch, fighting the fires as they appear, a bit of patchwork seems unavoidable. Everything is…
Author's value proposition is "I will help you outsource your complicated marketing tools". If you reject the gospel that your marketing tools are complicated, author's service would be not needed.
I like the ship analogy from the article. The fact it is so robust is not because the system as a whole is simple, but because its components have well defined, narrow responsibilities and there are abstract interfaces between them, which hide a lot of complexity. You don't need to understand the internals of the pump to explain what it does, even though the actual internal technology may be quite complex and clever.…
A startup is not a container ship going between port A and port B where everything is known. A startup is a new destroyer that has been floated, did not have sea trials and went to war with a crew that might have a couple of people that used to a drive container ship but mostly staffed with kids that thought it was cool to play with a destroyer. Oh, and 3/4 of the systems are still at best have been drawn on a napkin…
Earlier quoted context omitted.
I would really love to read their codebase.
What’s their stack?
The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's th…
A good example of how to do this would be London's Docklands Light Railway. A DLR train is capable of autonomously going from one station to another. Trained operators are aboard every DLR train, and they have a key to a panel in the front of the train which reveals simple controls for manual operation. But very deliberately the maximum speed of the train with an operator at the controls is significantly lower than maximum speed under automation (there are two modes in fact, driving with the train still enforcing rules about where it can safely go which is a bit slower, and driving entirely without automation helping which is much slower). This underscores that manually driving the train is the way to sidestep a temporary problem, not a good idea in itself.
The DLR has had several incidents in which trains collided, it will come as no surprise that they involved manually controlled trains. Humans are very flexible but mostly worse as part of your safety system, don't use humans if you can help it.
I like to “embrace complexity.” Any line of code, especially one that introduces a new concept, like a class or a method, is in “addition” to the root problem we’re trying to solve. The closer the code/data/org-processes/whatever matches the fundamental problems we’re trying to solve, the less complexity we introduce. However, you cannot “remove” complexity! A common mistake I see in software companies is using a sin…
Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…
Go is actually a pretty complex language, more so than Java for example, in my opinion. It has all sorts of primitives that you need to get used to, special rules for how the built-in types work, there are all sorts of rules to see what creates a copy of a struct and what doesn't, pointers have at least three completely different use-cases (optionality, mutability, and avoiding copies), several rules for what can and…
I'd say Go is able to put so much meaning to those fundamentals because 1. they have to, there isn't many other mechanisms 2. they can because it's still early in the evolution of the language. After some adoption and wildly different use-cases that users wants to be addressed, those patterns start to disappear and people end up with lowest common denominators, pointers being just pointers in this case.