No, I've been doing this for ~30 years now and I have really strong unpopular opinions on things. Like:
- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.
- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.
- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.
Those seem like pretty unobjectionable opinions. Have an upvote!
You want a controversial opinion (on HN), how about mine:
"It's not always a good tradeoff to throw something under the bus to save developer time."
So many important things are routinely sacrificed at the altar of developer speed and comfort, app runtime performance being the big one. It's used to justify all sorts of crazy things we do in modern software to ship faster, but so hard to push back on because developers are expensive and software needs to be done yesterday.
Some things are worth giving up so that developers can move faster, but I argue not everything. Need to evaluate case by case.
Like Wordpress optimises for edit functionality, at the expense of render speed. Most of the internet is now slow, optimised for Susan From Marketing because they don't know how to edit HTML.
Same for Ruby/Rails, same for Python/Django, same for Node/whatever. Web pages render slower so that whoever edits them can do that faster.
Last month I ran into The Principle of Least Power, and it's grabbed me and the more I think about it, the more it expands. I think all of your statements lines up with this principle, except one.
Containers are a simpler solution than Operating Systems. Operating Systems is a tightly bound non-simplistic system that breeds complexity, just as you state npm does. Because those interfaces are tightly bound, we were not about to build on top of them. Almost immediately after we got Docker, we got K8s. Once we got Docker we got the ability to manage these things at a higher level. That's the mark of a more simple solution.
Are there things that Docker can't do? Are there things that require so much performance that Docker can't handle it? Only then should you step back to the more powerful solution.
Not to say that there aren't problems with Docker. Dockerfiles have a lot to improve. Running containers has a lot to improve.
I think. I'm still at a state where I might change my mind. It's partially why I'm posting this.
yeah, no. Containers run on top of Operating Systems. They inherit everything that the underlying OS has. They're not simpler, they're actually more complex, but pretend to be simpler.
What you're thinking of is Unikernels. These are simpler than OS's. And yes, Unikernels are a good alternative to containers for a lot of applications we currently use containers for.
> Simplicity is an important design goal for all systems. Complexity breeds bugs
Counterpoint: some problem-spaces are inherently complex; most problem-spaces have hidden complexity. Complexity cannot be removed, it can only be moved up or down your tech stack, and obviously, you can needless add more complexity.
Docker, K8s and the like are perfectly fine when they fall below your project's complexity floor - they are good place to shift your complexity to as they are battle-tested and well-documented. If your projects complexity floor is lower than docker/k8s, then integrating them will just increase your solutions complexity needlessly.
Totally agree. Some problems are complex. However, that does not mean that the code needs to be complex. Simplicity should still be a design goal even if the problem space is complex.
I don't really agree that there is a "complexity floor". Things can always be made simpler, up to the limit of the problem space. As you say, complexity can always be added. Most projects do this. Very few stick to the minimum complexity. The complexity floor for most projects is therefore way below where that line is normally drawn.
This is the key. One of the harder things to do in software design is to find a representation of the problem that gets closest to that complexity floor. It's often not obvious.
> I expect to get downvoted because these are unpopular opinions.
Well, not really. These opinions are very common among my peers. We sold multi-million dollar transformation projects with the stated goal of making things simpler and easier to use and understand.
> - Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.
- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.
- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.