I think there's a few more reasons that the author doesn't mention.
1) It's actually harder to design things that are simple than complex - to take complex requirements, present and anticipated future, and to see the simple design hiding within. This is where you want senior engineers who have built up this expertise over time. As Mark Twain (but originally Blaise Pascal) once said "If I Had More Time, I Would Have Written a Shorter Letter".
2) There is a big tendency nowadays, not entirely bad, to treat projects as systems integration of whatever pre-existing parts can be had, and these parts themselves may bring complexity since they are made for more general use, and also be "impedance mismatched" since they were never designed to work together, therefore requiring glue and adaptors to make them work. Sometimes it's just better to write something suited to the task at hand than try to force something pre-existing to do something it is over-engineerd for, or not entirely suited for.
3) Resume padding. Software engineers like to use the latest greatest packages and techniques that everyone is talking about, and hiring companies are asking for, even if they are not that well suited to the project at hand. Sure, with some effort and extra code you may be able to incorporate some sexy new tech into your project, but it may be to the detriment of the project.
It's actually harder to design things that are simple than complex
This. In fact it’s often harder to even figure out what simple is until you actually try a bunch of things, and current corporate software methodologies don’t allow for iteration and experimentation to figure it out; you get one shot before the software’s even exists yet.
At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.
> At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.
"Quickly" is relative. If you can produce software quickly, that'll become the expected speed, so it's no longer treated as quickly and we will get back to the same situation.
Rapid prototyping is certainly a good use case for AI, but I don't see it really working for larger work projects where design complexity make be an issue.
Certainly considering how all the parts interact is part of brainstorming alternate system designs, but I think high level architecture / project-decomposition (design) has to occur before prototyping (coding) would be applicable.
Design/architecture by vibe coding doesn't sound good, but using AI to brainstorm different architectures (before any coding begins) might be useful.
While I do think there is some value to vibe coding, spending more time thinking about the final product is just as necessary and often lets you gleefully cut away many gordian knots.
Quickly exploring the implementation details is nice, but it's rare if they ever get in the way. What really gets in the way is shitty planning.
I like this -
Hubert Humphrey (VP US) was asked how long it would take him to prepare a 15 minute talk: "one week". Asked how long to prepare a two hour talk? "I am ready right now".
I'm not entirely clear what the argument being made is. Simple tools are simple, sure.
But there is an awful lot of complexity in otherwise simple things. Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I think, often times, people mistake the results of something from the tools that went into it. Such that it can be tempting to think that simple looking creations were made with simple tools. As often, the opposite is the case. It takes complicated tools to build something that looks simple.
Maybe the argument was that you put more effort and work into what you are building than you do that which you use to build it? I think that is largely fair.
That is actually somewhat in focus when discussing a pen versus the "penzilla." For one, building a pen is a surprisingly difficult thing to do. Especially at scale. For two, people rarely want to have a pen for the sake of owning a pen. Instead, you want to write something.
Which is very different than something being simple.
There's a lot of old sayings that capture this sentiment. "Simplicity is complexity resolved" (Brancusi), "Good design is invisible) (???), "The best craftsman leaves no trace." (Chinese Proverb??).
My favorite is "Sprezzatura"[0]. The act of making something look simple. IME, the mark of a true expert is they make their work look trivial. As if anyone could do it. It's bittersweet that this is the reality, because we seem to have fooled ourselves into thinking things are as simple as it looks ("pun" intended). It's a dangerous trap. Over estimating difficulty will prevent us from trying, but underestimating will make us foolishly spin our wheels. But I think we've built a system where we just normalize wheel spinning. It's true, most wheels are made for spinning. But if they're freely spinning in the air then your car is going nowhere.
> Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I would assume the power drill was created first if you include human powered drills, screws came much later than pretty much every other kind of simple machine, and until machine tools were invented, screws as fasteners didn’t really exist outside of specialized applications. They were used for presses and applying force.
John Henry was competing against a steam powered rock drill in the folk tale about him.
If you define power tools as tools driven by electric motors, I would still guess that the drill came before the driver, as rivets seem to be more popular in the steam engine to electric transition period than bolts or screws were.
Slightly confusing things is the fact that a modern drill is almost always a driver too, unless it’s a specific kind of drill like a hammer drill or core drill. Confusing things even more, there are drill bits that are meant to be used with an impact driver, a tool that is used to tighten or loosen fasteners.
As for which is simpler, drill vs (impact) driver, it’s hard to say. A drill has a clutch, and an impact driver has a spring mechanism that applies rotational force when the motor is at its limit. I’d say both are fairly complex, the impact driver is probably a bit more complex than a drill.
I’m curious about the development and history of power tools but it can be difficult to find information about it.
Your progression of "confusing things" happening several times is exactly what I was hoping to elicit. And is why I think it is a bit of a red herring to ask which is simpler.
Love this kind of comment, where one commenter poses a thought experiment about something I'm unfamiliar with, another commenter explains it in full seriousness.
Rich Hickey had nothing to do with it. He did put a lot of the initial work to get Clojurescript up and running but for many years the majority of cljs maintenance and shepherding was done by David Nolan. Not sure now; I've been out of the loop for years.
The Clojurescript community was the first group adoption of React outside Facebook (early on they had community news blog post and mentioned it) but that because the React rendering model fit the Clojure data model. I was active in the NYC Clojure meetup at the time (Rich was from upstate and would only come in for big announcements, and David was local) and we had 4 or 5 months where there was active discussion among the web devs after the talk on how to make cljs actually work. My memory is Brandon Bloom is the one who made the React connection. David picked up the idea and promoted it to the wider community.
I thought I could recall some post/article where Rich Hickey said something positive about React but I can't find it. Maybe I made it up in my head idk.
I think this is not the point of the argument. Power driver solves a problem, but not everyone has that problem. Some jobs just need a drill.
The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
> The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
I think this argument isn't valid. The problem that React solves is creating reactive user interfaces. React is trivial to use in it's happy path. The tool's complexity is a red herring because using the tool is trivial and effortless.
To me, this argument is based on specious reasoning. Take for example vending machines. They are trivial to use: pick a product, pay, see it drop and pick up your item. It's dead simple. Does it make any sense to whine that buying items from an automated system is a problem not everyone has, and that the vending machine is far more complex than a seller behind a counter? No. What makes sense is the complexity from the user's perspective, and what effort it requires them to achieve the goals they set forth to achieve. And React makes it trivially easy to put together highly performant reactive web apps.
> The problem that React solves is creating reactive user interfaces
The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.
This is potentially not the same problem that you are envisioning there, and it tends to put rather different constraints on the solution.
> The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.
Nonsense. React's selling points have nothing to do with repo structure or the number of engineers working on a project.
If you ever used React at all, you would understand that updating the entire state of the appocation after receiving any input is a non-trivial feature that React turned into a trivially solved problem.
On top of that, React adds modularity and composability.
I wonder if you're criticizing something you have absolutely no experience in.
why it does things the way it does is relevant - the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)
If you were building a state update layer without Facebook’s constraint of extreme scale, it might look rather different
(Also, I’m not criticising react - it solves a variety of problems well. If they are the same problems you have, great)
> why it does things the way it does is relevant -
Yes. React automatically detects the minimum set of changes to a DOM that is required to update it's state, and manages how those updates are applied to maximize performance. It transparently handles both app state changes, and basic changes to views triggered by updates to models.
This is a problem everyone in webdev has. Everyone.
Did you saw any of the comments here on how a little JavaScript allows people to update the DOM?
> the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)
No.
The reason why Facebook had problems with state management and modularity was because Facebook had to maintain websites.
The reason why Facebook developed React was because they had clever people who identified the problem and were given resources to work on a way to turn a hard problem they experienced into a trivially solvable problem.
Companies, big and small, develop their own tooling and infrastructure to improve efficiency, and they do it all the time.
Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
> people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
Alternatively, they do it because if you are holding a React, everything looks like it should be implemented using a React. While the finished product might be more complex than needed, it is less complex for them, because they have used a tool they understand well.
> Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
No, not really. There is more to picking up a tool than some rando's simplistic drive-by judgement. For example, say you have a React SPA managed by a team which built and manage their whole platform, from the CICD pipelines to the hosting solution. All your infrastructure was built around providing a React app and it's backing services. You are then suddenly faced with a need to implement a feature where a user after clicking on a link navigates to a page that just shows static text. Now think. If you implement that page with React then that's a one-point task. Just create a component, fill it with text, post a PR, done. What level of effort does it take you to implement that with another technology? If you go with the simplistic take that plain HTML is better, now you need to set aside time to sort out support for styling, sort out where and how to deploy those assets, work on a process to automate the deployment, etc etc. Now your simplistic drive for simplicity turned into something between a week and a month's worth of work requiring infrastructure changes and adapting deployment strategies, all of this requiring not-so-trivial QA and testing work.
What problems did you solved? Can you describe your system as simpler, and keep a straight face?
You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.
> You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.
Not really, the article is about a belief some other approach would be preferable based on superficial and specious reasoning.
My example proved that this kind of superficial and simplistic analysis fails to account for critical aspects which are key to explain why a decision was made.
This doesn't go away by complaining that I refuted your point while I could easily not refute it.
The whole argument is silly, if you think about it. What could possibly possess anyone to believe they are the only ones who know better and everyone else in the world who disagrees is stupid and doesn't know what they are doing?
I'd certainly be interested in seeing what kind of websites this guy produces that are written in "javascript". If any. And it is rather damning that his own website that host the blog is written in react, not "javascript".
> The argument is valid and doesn't need over analyzing.
No, it isn't. A big part in your failure to understand the problem is your refusal to look at what you're doing, which you try to dismiss as "over analyzing". As if reaching the conclusion that a simplistic proposal brings unacceptable tradeoffs means you are looking where you shouldn't.
> Using react for simple simple things makes it not simple.
Did you actually took any time to think through that assertion? I don't think so. For starters, you didn't even stopped to think why React is used at all. Why was that?
Right, my point was more that thinking you can guess the simplicity of a solution based on the complexity of the tools used to build it is a bit misleading. If only because most simple tools are far more complicated than that allows.
Similarly, I would argue that using complex tools to build something generally results in less complicated outcomes. Our computers are basically evidence of that.
Difficulty of use and reliability don't seem to have any relation to complexity on mass-distributed products. Costs depend almost exclusively on scale, and not on inherent properties.
Actually there's lots of times I want to use my hand driven driver rather than a motorized one.
I agree with the other comment mentioning analogies have their limits. Are we going to pick them apart just so we can avoid listening? Communication is lossy. Are we having a conversation or just trying to win a game of our own design?
I add that because how I interpreted taeric's point of a drill and a driver is just a variation of "apples and oranges." You can concentrate on how they're both round fruit or you can recognize there's differences. I mean walk into any machine shop or go to your uncle that likes to make things and have them explain why they have so many wrenches of the same size but in different styles. Often the subtle differences are the most important part. Hell, how many people even know what those numbers do on the power drill? Making use of them really ups your game. Same with adjusting the power level on your microwave. Yet I rarely see people use these things which are highly effective and help avoid many common mistakes.
I wasn't trying to pick the analogy apart, I thought it was quite a good one and was running with it. I think it breaks apart though when you start talking about minor differences in wrenches though - it's not like the difference between Vue and Solid will make a significant difference when building an app. But between a screwdriver (jQuery) and a power drill (js framework), that can be very significant.
Analogies have their limits. That being said, there is always a learning curve. Imagine a situation you want your 5 year old to assist you, but you don't want to teach them how to safely use a power drill.
Yeah for sure. Sometimes my drill is not charged and it's easier to grab a screwdriver and give it a few quick turns (https://benton.codes/blackberry), or maybe I can't fit the drill in some space.
But normally I'll use the drill even though it's overkill, because I got other stuff to do :P
I see you've never seen or dealt with a head blown out of a fastener. A drill has basically no feel, and things escalate quickly especially for marginal fasteners.
Cordless drills for driving screws have clutches. Also, you have to always make sure to use the correct bit. It doesn't matter whether you use a screwdriver or not, you'll strip the screw with the wrong bit either way.
The argument is that certain tools introduce complexity into a project by the mere act of using them. A power drill has many more knobs and features that the user must be aware of than, say, a screwdriver. Sometimes those features are required, but often developers will gravitate towards such tools even when they're not.
In software development this applies not just to external tools, but to abstractions in general. We might be tempted to create or depend on an abstraction that solves many problems in a generic way, when in reality this could be avoided. The appeal is to reject this temptation whenever possible.
Simplicity is an amorphous quality without a clear path towards it. It's often debatable whether a system is simple or complex, given that most software is built on extremely complex machinery we take for granted. But the least we can do is to be mindful of practices that lead to a net increase of complexity, use critical thinking instead of blindly following trends, and, sometimes, take the more difficult road for the sake of preserving simplicity.
React piles concepts into your mental backpack: rendering models, hooks, state libraries, routing, and a build pipeline. ... The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework
Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".
The whole reason frameworks exist is to _reduce_ the mental backpack by using something that has solved the same problems in the same orderly way.
I'd argue the whole point of React is to enable the modularization of components written in Javascript.
I realized as soon as 1997 that if I wrote some component in Javascript I wanted to stick into a web page I might want to stick two or three of those into a web page and to do that I have to keep the state for those separate, be able to reference the form elements (didn't have access to DOM elements!) with a unique name, etc.
React goes past that and lets you nest components into other components. In some point that's "managing complexity" and not "introducing complexity", except for the fact that when you can easily incorporate 35 third party components into your application that is 35 components each of which introduces its own complexity of one kind or another -- some of the complexity of "modern Javascript" is the complexity of the build system and the framework, but the build system and framework system let you build bigger systems that have bigger problems.
That's not really an accurate statement of Jeavon's Paradox. In this case, it would be "when everyone has better tools, people expect better websites."
> Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".
The ultimate step into irony is reaching a point where, to justify their approach, they claim that it's ok to spend all this time reinventing JavaScript wheels because all this "sprinkle-on" JavaScript can be packaged and reused in other projects.
I'm glad they at least had the bravery to provide a concrete example of what they mean by "complexity". Clearly their example of "React = complex" vs "JavaScript = simple" is actually a fairly controversial take. Does "simple" mean "better", if not, I think we should be chasing the latter.
I'm not even sure it's a controversial take, more of react devs (don't worry, myself included) feeling called out and getting defensive instead of trying to understand something simple.
Ask a biologist or ML enthusiast; complexity is the natural outcome of a period of mutation/selection. It's a mistake to criticise the result on the grounds of said complexity, I think - rather ask what environment the complexity evolved to "survive" in.
It's boring common sense but don't take a bromeliad into the desert.
My belief is that all codebases that live long enough will develop this level of complexity with time. The only exceptions imo are where the codebase solves a very particular, fixed problem, e.g. a library for A* pathfinding or whatever. But maybe not even then.
I think this covers nicely discussion about the HTML, CSS, JS and browsers complexity from other thread.
We have a bit of messy complex system that we can run cross platform applications including mobile.
But it was only one that could survive corporate greed and shenanigans where all other UI toolkits and frameworks are limited in one way or the other or entirely dead.
People nag about the complexity and messiness but there is no other surviving alternative.
Often times, as bad as it sounds, the business value is forgotten by developers who criticize these systems.
Like these systems are already in place, it would be an unrealistic undertaking to exchange them with "less complex" systems.
Businesses unfortunately have to make money, rebuilding something they heavily rely on is not something they can just do (Part of why so many corps are vendorlocked by SAP). Also, where are the less complex systems? I did not see anything as flexible and easy as web tech. Even though it pains me how unsafe it is.
It's Conway's Law. Companies ship their orgs, and the people shaping the org are not approaching it with CS fundamentals. This means they will slice and dice the domain according to some arbitrary, probably business driven, criteria. These become teams, and the teams then add code with boundaries around these arbitrary divisions. This adds a ton of complexity and entropy. React is basically designed around this. React favors flexibility and "developer experience" at the cost of performance and complexity.
I like my colleague Simon Morris's observation about software complexity:
> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility.
> Build pyramids if you must, but build them like the Egyptians did: with a clear purpose
For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids? Maybe the rest of this will fall into place for me when I understand that.
To build a tomb. Not a shrine, not a place of worship, not a functional structure. Not something that could be repaired or repurposed. A tomb and nothing else.
A purposeless pyramid would get bogged down with plumbing and fountains and extra passageways and observation decks and on and on and on. It would have been impossible to build.
IIRC, their society depended on it. During peacetime, it was a major economic engine paid for from the royal treasury, with the work starting as soon as a new pharaoh ascended the throne, and the labor provided steady work when agricultural activity stopped due to Nile flooding. Of course, it's only in hindsight with our modern understanding of economics that we can see how such an activity at face value not important to any basic survival need was in fact a key piece of the economic fabric.
> The Roman writer Pliny the Elder, writing in the first century AD, argued that the Great Pyramid had been raised, either "to prevent the lower classes from remaining unoccupied", or as a measure to prevent the pharaoh's riches from falling into the hands of his rivals or successors.
It was a Keynesian anti-cyclic wealth distribution program.
The jobs did come and go as necessary to maintain stability. It was reasonably well paid, from money collected taxing the luckiest farmers at the good times, stored as a community project.
It's really impressive how the Egyptians created this kind of organization and maintained it for thousands of years, when no government seems to be able to maintain something similar for a decade today.
> For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids?
For them to be able to properly descend to and navigate the afterlife of course. This is why society today is so broken, all we get for our afterlife is a shitty urn and some bland sandwiches.
Its because "reality has a surprising amount of detail". It is actually the rare occurrence where a simple solution solves a complex problem. I link an excellent article that has been posted on HN multiple times, that explains exactly this.[1] (not mine)
This is very apparent in my work right now, as well as "all models are wrong, some models are useful".
I'm parsing some "simple" CSVs into a DB, but I have to keep the concrete representation intact for another purpose. The DB format will be similar to the CSV format, but can't be quite the same. I would've figured this would take a day or two (I've written many parsers before), but the amount of details I have to consider has lead me to circle back to this problem for a long time.
If we used ascii delimited values none of this would be a problem. The amount of effort spent on csv must be close to a million man years and all because we want to edit the files with a text editor without a special mode.
The files are CSV-adjacent, I should say. The issue here isn't the delimiter in fact, it's the fact that the format differs slightly between files, even within the same project. That, and the mismatch with the SQL DB format I want.
After rereading the post I realize that the op was talking about the schema of the files rather than the adhoc nature of trying to decode escape characters.
Not sure if it's just me, as I'm relatively new to the field, but I notice a surprising amount of people assume that the details in programming have already been made intuitive to them, and they use this "experience" to push ideas that are at odds with other domain specific details. To me, maybe this is what the author means by "stuck"?
> If you’re a programmer, you might think that the fiddliness of programming is a special feature of programming, but really it’s that everything is fiddly, but you only notice the fiddliness when you’re new, and in programming you do new things more often.
Paradoxically in SW development complex things often appear because it's easier (simpler) to 'just add this check here' instead of rethinking (and remaking) previous solution with updated understanding.
'We'll fix this later, now just make it work'
It takes more effort to make things simple than to make them complex.
> Paradoxically in SW development complex things often appear because it's easier (simpler) to 'just add this check here' instead of rethinking (and remaking) previous solution with updated understanding.
I think the issue is actually deeper than that. To start off, the definition of complexity that's used is often partial and incomplete, leaving out entire domains where complexity manifests itself.
So it's often easy to make swooping statements about what is complex and what is simple, because what appears to be simple is actually offloading the bulk of the complexity somewhere else.
Take for example CICD pipelines. They can be very complete, thorough and complex. You can shave off part of that complexity by doing manual work. Do you get a simpler system if you replace a pipeline with manual work? No, you get a system that's far more complex, unreliable, and brittle. So how come no system is more complex than introducing a system? Where does the complexity lie?
I don't think that's paradoxically, that's just the reality that changing a little thing is easier then considering all cases the code has to handle and figure out a solution which addresses all
What's paradoxically imo is that often - when someone does decide to remake it in their vision... It's usually isn't improved - heck it's often even more complicated after the refactor.
The other day there was a guy here on being mad about my program/code being simple.
bro, like what? if i can make living from simple things why will i complicate it? It just seems some people complicate things to justify their pay which later becomes difficult for their organization to maintain.
No wonder the guy was not accepted at FAANG where code maintainability is utmost priority.
Lots of engineering disciplines enjoy complexity. It is challenging, and doing challenging things feels like an accomplishment, or demonstration of skill. I think software gets away with higher levels of complexity than I typically see in other engineer disciplines because it has a lower negative impact from the perspective of the business or the end customer. In auto manufacturing, for instance, complexity not only increases r&d costs, it also increases performance unit costs, and typically reduces reliability and maintenance costs (both of which are usually visible to end users). In software, complexity may appear to reduce r&d costs by reusing code in suboptimal ways, but the end effect is marginal slower, marginally higher binary size, and higher maintenance costs, but the end user doesn’t really ever see the direct maintenance cost, just a subscription price or support contract.
Imagine reusing an entire physical assembly for only one of its functions (eg a microwave to get a clock) this is the sort of thing we do in software all the time, but would immediately fall apart in other disciplines.
You can see if a motherboard has twice the necessary components, or if a robot arm just looks wrong, but if your algorithm to process 1000 records takes a thousand times longer than it should (but still finishes in 100 milliseconds) no one notices.
Until it has to process stuff in real-time that is.
A robot arm is exactly the place you see software acting up. If your algorithm is consistently slow it's fine, the moment it's inconsistent things dont line up and problems happen.
All that build-up, only to culminate in a slight dig at react?
> React piles concepts into your mental backpack: rendering models, hooks, state libraries, routing, and a build pipeline. Say no to it, and suddenly you’re the “neckbeard stuck in the ’90s,” outside the cool-kids club.
Out of the list of the piled concepts, only 'hooks' would be react-specific. The rest are the concepts that a front-end developer will need to think about anyway if he builds a standalone client. If the client is built using non-web-standard languages; or even if static file names need to be stamped with hashes for proper caching, developer has to think of a build pipeline. If the client is decoupled from the server, developer has to think of routing. If things happen on the page in response to user interaction, developer has to think of rendering and of client-side state.
React isn't guilty of any of this. There are plenty of things it is guilty of; but these aren't the ones.
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed
Is it simple though? From my experience, apps written with "sprinkles" tend to become very complex very quickly. Unless the author means something else by "complexity".
I see a coming soon page one time that had a background image, a logo in the middle and 5 lines of text. That was the entire thing. Wondering why it took so long to load I view the source. 30 js files, 5 css, a hundred html tags with 10 classes each.
Wondering the same visiting a web shop I found a seemingly infinite amount of js. Digging a bit deeper I ended up getting lost in some enormous library for rendering unicode smiles with data uri's. It seemed like a good idea as each page was already making many hundreds of requests. If they add 100 smiles to a product description it probably never loads.
In my experience you can avoid things getting very complex by just refusing to add new "features". If that is out of your control it isn't your fault. Build them the pyramid!
Why do some folks love assuming walking backwards to the past is the only reasonable path?
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
Having grown up doing webdev at its emergence, those were not glorious years.
Even as a solo developer or part of a small team, it was hard as hell to have a perfect mental image of the app at all times, to understand all the combinatorial possibilities of what state your app is in now and what state you want to head to next.
Trying to forever update retained state is hard as hell, full of incredible opportunity for memory leaks, and created some super weird behaviors.
Even more so, "just write the basic code" doesn't scale. It's not a system that an org can follow. Folks will come and go, each going totally different directions. I don't know how to stress how immature and insane this sounds.
But folks love trashing that which is popular. To declare oneself the only sane mind amid a sea of madness.
I really do hope we see some post-React eras dawn, see more, that this isn't it, on and on. But I respect like hell the switch from a retained mode form of webdev to an immediate mode one. It doesn't just skip by so many really bad failure modes, it's often far far faster than the poor incomplete hacked out vanilla.js solution your org ended up with. I want us to change to move to not be stuck here. But to see where we are as unnecessary complexity, to invent fantastic degrading tales about the weak souls of men for getting us here: this is truly the behavior imo of lowlifes, of those spreading propoganda to spread the thinnest false confidence of hatred and disdain against the world.
Things are complex and that's ok. We are learning. The way out in onwards not idolizing a concocted naive pastoralized past.
This comment is on point, so all I'll add is this:
> The way out is onwards not idolizing a concocted naive pastoralized past.
Ah, the noble JavaScript savage of 1999 - so in tune with his environment, his nose twitching in perplexed confusion as the unfamiliar scent of DHTML wafts past.
Unconcerned with a future that he cannot possibly imagine, he launches Dreamweaver and begins coding, secure in the knowledge that the more things change, the more they stay the same.
You're right that immediate mode is great and makes life so much easier but for most use cases, React is very much a "retained mode" framework. If all of the valuable state in your app has its source of truth on the server (majority of apps), then retaining any of it in React state soup is unnecessary complexity.
People like to bring up how terrible it was to do vanilla.js in the old days but completely ignore that we are not, in fact, still in the old days. Native browser APIs are so much more powerful now and a ton of the pain that React was made to solve is even now handled declaratively with some simple HTML and CSS. No hacked out JS required.
Yes the 90s and 00s were rough for js, especially because of where JS and browsers were at, and also our collective knowledge.
However also it was much nicer in many ways -- we weren't trying to make insane single-page-apps like today.
The irony is that we have all of these powerful frameworks, but somehow they seem to mostly make worse/slower websites than this silly 0-javascript orange site we're on right now.
Simplicity is borne out of messy, complex stuff. That one then has to do the work of removing the stuff that doesnt matter / rethinking how stuff fits together.
Most people dont really have the mental energy or discipline to go through this process, so by on large, complexity exists in the world.
That an entire population wide brush ya got there. Not true at all. In many many cases, an initial implementation that is supposed to be figuring out the problem is never revised, just shipped. All these "complex code bases" are premature code that will never see maturity, just patches by an ever increasing population that understands the problem less.
> What? You don’t know how? Okay, instead, sell me this Penzilla - a pen that can erase, write in different colors, play music, dial 911, act as a radio antenna, and even help you cheat on your homework.
Anecdotally, I read somewhere (and agree) that the reasoning behind the "sell me this pen" question is to quickly identify whether someone has the most basic skill necessary to become a decent salesperson: asking questions about need and listening to the answers.
I'm guessing the author of this post does not work in sales (hardly a bad thing) because "selling a pen" by listing all the excellent features of the pen and why it's better than any other pen on the market is exactly, according to the theory, what you should not do.
Do you use pens? What kind of pens do you like? What bothers you about the pen you've got? Well, if this pen doesn't have any of those issues, why not just buy a hundred of them right now and stop wasting mental energy on what pens to buy for the next ten years?
Weird take: rather the opposite in my team. We look for the simpler solutions due to maintenance burden. Also, we actually deal with very complex tech; virtualization. Our whole premise is to create tooling for convenience, which therefore involves abstractions.
Some complexity in that case is needed, but its aim is to provide a cleaner/simpler access, which is often opinionated, limited to the purpose we have: deployment of development tools for containers.
If you want to experiment, show off as the article implies, start a hobby project.
Edit: removed some fat-fingered typos when I wrote this on a phone
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
I worked with a front-end developer (React) who needed help integrating with a payment processor. I looked at the docs and hopped on a video call with them to get them unblocked. I ended up having to explain how to POST hidden inputs via an HTML form to them, and their reply was something along the lines of "Oh, HTML is obsolete." They didn't understand the basics because they only new React.
I think complexity used to sell (real architects used abstract factory factories). Today, simplicity sells and while far better I think it can lead people to do dumb things sometimes. There isn't any problem with simplicity of course but rather what people define simplicity to mean. Sometimes it means things like "let's write our own database", because it is "simpler".
Right now, "simple" is meant to translate as "good" for the reader and whatever writer wants it to mean. I'm glad, at least, that the article provides an example (React vs plain Javascript). I don't know for sure but I suspect there are at least some valid arguments for using React vs just grabbing dom elements in Javascript.
I don't think we're gravitating towards complexity. It's much simpler:
1. We add more functionality to the base of what exists (e.g. HTML). More and more individual features. (e.g. selecting things in the DOM, animations, effects, interactions, tracking state)
2. At some point someone takes all the patterns in the latest wave of functionality and writes a library for them. Library is widely lauded or adopted (see jquery, React).
3. We think of new features building on top what is now the new norm, it's now table stakes. Rinse and repeat.
This is a common pattern in engineering, for example writing new entries to a DB, then at some point going back and compacting.
While I don't doubt that trying to "show off" or "job security" is a reason, I think another big one is because too many developers have no knowledge of the low-level basics to even consider that things could be simpler, having only been exposed to overengineered code and indoctrinated in the belief of abstractions as the ultimate panacea. To relate to the example of React and JS in the article, there are likely many web developers now who have never written a single plain HTML page and always started with the minimum React SPA, so they don't realise the former is even possible.
I have a bee in my bonnet about this software complexity issue. Perhaps it takes large amounts of humility to accept that your job is fairly mundane, and only needs simple code to get the job done? I mean: who wants to turn spanners on a Toyota when you can imagine you're working for NASA, and introduce fascinating new paradigms to your work, that ultimately add complexity. I suspect that's why i've joined so many teams that have tied themselves up in knots of un-grok-able indirection. Another theory I have is that people encounter bad code, and misdiagnose it, identifying the (wrong) solution as needing a big complex architecture.
There you go. Instead: compression, efficiency and speed are better traits of intelligence in software engineers building these systems and being aware of trade-offs.
Rather than building rube goldberg contraptions and not only it is difficult to refactor them but can kill the entire business if the maintenance costs continue to increase.
If you really want to work with the most pretentious, attention-seeking, optics-loving people, work in robotics. God dammit, how I love the field, but most people there are insufferable.
The reason why the pyramids worked is because they never had to CHANGE.
Changing realities drives complexity, and the more chaotic those changes, the quicker the complexities pile up.
If you look closely at the pyramids, you can see that the later ones were much more solidly built than the former, having learned from past mistakes. But the reality around them hadn't changed (and still hasn't after thousands of years), so every iteration became more and more efficient since they were building anew each time.
Not so with software! Every time you iterate to make something more efficient, every time you're forced to react to a changed reality or imprecise model or failed assumption, it still has to fit into the overall system and keep working somehow. And that could mean working with a system that has a fundamental assumption that doesn't even hold true anymore, and would require so much work to fix the assumption that it's not worth the cost to fix.
The main benefit of software systems is that they can be reprogrammed to deal with changing reality. The downside is that these systems operate on entropy. That's the trade-off.
We like to scoff at old, "crusty" systems and the morons who didn't know what they were doing, but this is the fate of all software. The difference comes from your stewardship over the project, minimizing the impact of the entropy that constantly assaults what you've built. The Linux kernel is a good example.
The pyramids analogy may lead to a different line of reasoning: not only they look useless (making all the effort and complexity put into those unnecessary), but at least Aristotle claimed (not sure how accurately though) that they are made to keep people in poverty and occupied, in order to preserve a tyranny. Akin to the modern concept of "bullshit jobs".
The list of accidental complexity sources looks rather short. Off the top of my head, I can think of CV-driven development, of developers not being aware of basic tools, reaching for heavy and marketed ones instead, of awkward regulations pushing to silly solutions, of simple incompetence, of the NIH syndrome (or does that qualify as "creative temptation"?). The "Legacy systems and technical debt" point is applicable to newly developed systems with poor planning and strict deadlines as well. And then there are all the arguments about what is simple and elegant (or not) in the first place.
I read once that organisation is in favor of entropy. When a system organises itself it "consumes" more energy. And I think complexity could be seen as a sort of organisation. So in this case complexity is just the tendency to participate in time.
An example being the increased inefficiency, and rate of fuel consumption of aircraft with quadratic air resistance.
Some types of complexity have well formed mathematical definitions. Cyclomatic, time and space, kolmogorov, etc.
Something that's complex to the intellect is ill defined. I suspect it can be defined, but it's very highly dimensional. That is there is no scalar complexity number that can be used to compare items directly, and instead you may have two solutions of equal complexity but in different (and otherwise incomparable) axis.
The issue we have today is that we have no academic way to approach complexity so people just sort of develop an intuition for the subsets that they encounter and get bitten by.
However, because they have only a partial picture, they end up simplifying the complexity they do understand in a way that increases the complexity that they do not understand (at least until it's too late for the project).
Gravitating toward complexity is inexorable because simpler systems are prerequisites of more complex systems. We see the same thing in evolution--it's not inherently directed, except in this sense of prerequisites. Systems can go from complex to simple (e.g., viruses), but complex systems cannot leap into existence -- see https://www.tedcloak.com/uploads/4/5/3/7/45374411/gregory_-_... -- they appear over time, via accretion. Scientific knowledge largely works the same way -- there are prerequisites. e.g., Einstein's concepts were seeded by the Lorentz equations, and of course Newtonian physics.
Of course biologically evolved systems don't occur unless there's some fitness function they satisfy. Well, complex software also provides desired functionality--sometimes the desire is just a result of marketing, but often it's due to real needs.
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.
Phenomenal post that reads like a developer’s version of my IT rant on the same issue: stop needlessly overcomplicating things for the sake of complexity alone.
The difference being that, at least in my side of the technical sandbox, it’s often along the lines of dissuading someone from propping up a K8s cluster for what’s better suited to a single VM, or stop shoehorning multiple overlapping agents onto endpoints instead of properly utilizing what you already paid for elsewhere, or stop carving out exceptions to policies and procedures that make support and maintenance exponentially more complex.
Complexity is a bug, not a feature, at least for 99% of use cases. The problem is that everyone seemingly thinks they’re the 1% that justifies said complexity.
Managed Kubernetes is easier than VM. It provides high-level concepts, allowing you to deploy programs with less friction. It does it at a cost of complicated programs running below, but you won't find simple things. Modern CPU alone is insanely complicated machine. You can achieve simplicity by building your product on complicated foundations and Kubernetes is one of these foundations.
Another example of complexity is compiler. Even assembly compiler brings a lot of complexity for modern software. Yesterday I wrote dumb empty program with 3 assembly instructions to syscall exit. To link that program, I had to deal with the following sections: .rela.dyn, .rela.plt, .plt, .text, .note.gnu.property, .got, .got.plt, .data, .bss. Of those sections, only .text contained useful data, but GNU software generates them all and wanted my linker script to handle them all. I spent few days researching about it and I still have very little idea what's happening there. And that's the lowest layer possible: x86_64 assembly. For something as simple as C language, it'll be magnitudes more complex, with plethora of C standards, GNU extensions, compiler optimisations, hundreds of compiler flags.
IT is complicated and there's nowhere to run. You can only choose some building blocks, pretend that they're fundamental and simple, and build upon them. Most C programmers probably ignore all those sections, have no idea what they do and just let default linker scripts do their work. But the sections are there and complexity is there, it's just hidden below layer you usually look at.
Bikes used to be fairly standardized to where you could do most builds and maintenance at home . Now there are hundreds of subcategories , parts are bespoke to the bike , and standards have all been obliterated. Duty cycles are very short . Brakes , BB , headsets , bars , axles , cassettes , freewheels each have half a dozen formats . Bikes are practically disposable. Costs are up over 10 years and quality on many aspects has declined .
There are hundreds of boutique brands and almost none are making any money. No one sensibly pays msrp you can find bikes 60% off easily.
When you think about productivity , in terms of how much utility can be produced by one person, it’s obviously declining . We have more tools, but the bulk of the effort has gone into getting attention rather than providing utility . Even the product development is more about marketing than utility
Meaning, as we invent tools that showcase a novel use, further ideas for how that tool can be used start coming to mind. A nail can hang a picture. If a picture can be hanged on the wall, what else can? Larger wooden shelves can be hanged on the wall if we improve the nail by adding a fastener. Now it's more of a 'mount' than a 'hang.' And so on and so forth.
The overarching question be: "what else could the nail hang, if the nail could hang pictures?" "could it hang everything?"
I think engineers like complexity. We like the ability to control and shape all of our tools.
In my experience, non-engineers, tend to like simplicity.
I have learned that there's a lot more non-engineers, than engineers. Many of them, have a lot of money, that they are willing to spend on things that are simple.
Working with graphic and interaction designers has taught me to suppress my resistance to making things simpler.
No, that's not my experience or understanding at all. Complexity is a byproduct of building something without understanding how all the parts fit together and without having a clear vision for how it will be used. The pyramids were built as monolithic monuments to the glory of a ruler intended to last millennia. They had a clear vision for what the end product should be, how it was going to be monetized and where material and labor was going to sourced before they laid the foundation.
Engineers thrown piecemeal at the edges of a problem will generate complexity. Engineers thrown into a room with a vision for what needs to be built and time to work out an elegant solution will get you to the moon with a pocket calculator.
If an engineer designs something, it tends to be complex, regardless of whether or not the designer has “the big picture,” because they design the whole thing to fit their worldview. Engineers have a complex worldview.
If a UI designer designs it, the chances of it being simple (from a user PoV), is much greater.
Designing a simple UI, in my experience, is often “un-simple,” however. I remember writing a visual cropping algorithm, for a film scanner.
It was a pretty damn hairy library (it ended up being an entire subsystem).
Worked well, though, once I refined and debugged it.
The UI designer might be capable of designing a simple UI but probably has no idea how to design a simple infrastructure, dataflow, logistics, corporate operations infrastructure, finance structure...
You're thinking like a UI designer that's watched engineers without UI design experience try to design a UI. You're referencing a lack of expertise and experience, not some inherent trait in engineering.
People are like a gas, they expand to fill the space they're in. If you have simplicity, you can always just do "one more thing" until eventually you've blown past your ability to understand / maintain / control what you've built. People can't help it, and I believe it maps directly to overeating, homes filled with junk that no one needs, debt, and many other excesses.
To be a good engineer you had to be stubborn in the early days of your career, you had to have tenacity and persistence to understand and solve the problems you saw. Unfortunately that filter selects for people who are prone to going too far into the detail, who get a satisfaction from conquering complexity rather than avoiding it. Given the lack of big picture thinking, they readily fall into herd-like behavior. Given the ego payoff for the complexity, it is very difficult for them to accept criticisms about their process or lack of perception.
It plays the same role as feelings to common folk. In other words, most people out there live for feelings: they seek good tastes, smells, comfort and so on. That's their purpose in life. More sophisticated folks collect art or watch opera for the same reason. Brain-heavy individuals enjoy well arranged complexity instead, it provides the sense of mental comfort. All of this stems from our ability to perceive harmony, although in all these examples our ability is glued to lowly things of this world.
The better analogy to pyramids was made by Alan Kay. In lack of an arch we get things done with brute force and thousands of slaves. Sprinkling JavaScript will not help with this issue.
If there was one reason people gravitate towards complexity this author is talking about, it's probably because they want to see if they can do it. In some contexts it's annoying, but it's also what moves the needle from time to time.
Unsure. Personally I like simplicity and avoid complexity. Sometimes it can be avoided. However two adages come to mind, "life is complex", and "complexity must live somewhere". Simplification only works so much and is inherently eliminating something that someone or some situation requires. This of course an over-simplification. ; )
I'm not a very clever person, and I keep things pretty simple, so when I explain something to someone, they can generally get a grip on it pretty quickly.
To them it's been such a small jump they think, that person doesn't deserve much of a reward, heck I could have done it.
Whereas when someone talks about the complexity, people think, wow, there's no way that I could have done that, let's pay that person LOTS to keep them
Flags became simpler and simpler, until they were just two colored stripes with no elaborate drawings etc. Simple is better as long as its enough, its both easier to spot and easier to make, but it is hard to realize when a simple thing is enough so typically people make complex things to be sure it works.
Technological complexity is often like a warm blanket you can wrap yourself in to avoid the realities of the customer.
Many businesses are built in such a way that you have little hope of directly contacting your customer, but that doesn't mean you can't try. The desire for complexity often disappears like magic when a developer gets to experience a client expressing happiness over the end results of their "clunky" tech stack.
Just have a text config file that comes in a variety of preconfigured flavors ("x mode", "y mode"...) and then also offer a "make your own config" option too.
Most of the time, if I'm working in blender for example, I want some really sane prepopulated shader values and one size fits all rig values for sofas vs chairs, but sometimes I want to go crazy and make chairs out of glass and slime, etc.
When you're 6 procedure calls deep in a model you started from some abstraction on the problem which has hit "well ACKchewally.." variances from the model, it's high cost to go back to top and invent the top level abstraction again, to be only 5 levels deep when you hit the next one.
Putting a late stage "yea I know, but this one time..." hack in, is logistically simpler.
TL;DR we're not addicted to complexity, we're addicted to the abstraction we started with, even when it turns out not to be as good as we thought.
This rings almost true for me - but “addiction” makes it seem like some sort of personal failing, whereas I think the cost of that backtracking and the probability of finding another Balrog in the woodpile later makes it seem like a perfectly reasonable choice.
Not sure in what context I need to answer this question, but thought is its the complexity created artificially when work culture, work politics, people and their thoughts collide together and resulting in a multi dimentional complex environment
It's because if you're building a skyscraper and you decide - oh heck, who needs architects and steel - that's too complex. Let's build this simple and use plastic.
Simplicity requires a deliberate planning consideration plus additional effort to maintain, often through refactoring once new requirements surface to implementation. For some people these additional steps are essential to main clear output and a single deliberate path forward. For other people these additional efforts are an impossible chore best offloaded to some third party.
These thoughts about simplicity apply not just to code but to every decision in everyday life.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." - Edsger Wybe Dijkstra.
Simple/complex is subjective. Software domain is very diverse that it's unlikely we'd agree on them.
Take mathematicians, for instance. They generally have a shared sense of elegance/beauty. That's the result of a refined intuition from years of study.
Not sure why your comment was not received well by everyone here, however, that Dijkstra quote is definitely pertinent.
I believe that anyone can make something complicated and only the few can make something simple. This statement can be read the one way, I don't mean that anyone can make a lunar lander or an atom bomb, what I mean is that over-complicating something is something anyone can do.
At university I discovered another aspect of making things simple. We had one assignment to design a multi-storey car park. The purpose was to demonstrate the use of diagramming, and I handed in a single A3 sheet of paper, whilst all of my coursemates handed in sixty page bound documents. I felt that I was taking a bit of a risk but I was happy with elegant simplicity.
When we got our assignments back, everyone else had a mark and lots of red lettering. I just had a singular tick. I bravely plucked up courage to ask what the tick meant. Our lecturer told me that I had a perfect mark and that I was the only one to understand the assignment.
Since I was not confident in what I was doing, it required a lot of strength to resist the groupthink of the course. I could have folded to crib someone else's solution to turn in my own sixty page monstrosity.
Getting back to web development, I have frequently found myself working with colleagues that go for complexity because 'anyone can make something complicated' and because they lack the confidence to escape the groupthink that goes with doing so.
They seek validation for accomplishing tasks in devious and circuitous ways, and to feel in control of something since they never had that anywhere else.
I think people don't realize how complex simplicity actually is. FFS, we've all see Conway's Game of Life, right? We all solve hard complex problems by solving simple ones, right? Yet, we have a hard time recognizing that simplicity is complex.
The truth is that simplicity is difficult to implement and even more difficult to maintain. It's easy to oversimplify, as all you need is to not be aware of some complexity. Given that there's infinite depth to things, it's always going to be easier to be missing information than to have enough. But then simplicity is difficult to maintain. Because each time we touch something the same process happens, causing things to compound. If you're 99% "good enough" (a pretty high and unlikely number) then 10 times and you're at 90%[0]. Often a small mistake can lead to big problems. If things run without much slack, then things break. Entropy is a bitch.
The way I think about it is the inverse of how we problem solve. We solve big problems by breaking them down into small problems. Their composition solves the big problem. Consequently, any big problem is composed of many small problems. So I don't understand why we are so dismissive of the little things. The difficulty is figuring out which little problems meaningfully contribute to big problems and which little problems have little impact or are contributing to a different big problem. So when we use dumb thought terminating cliches like "don't let perfection be the enemy of good" we're ignoring the reality of the issue here. If someone believes perfection exists, yes, fix that. But only really junior people think that. Far more often it is a disagreement about what is "good enough" and so the cliche just prevents having a conversation to figure out what that is. No one is omniscient, so why not hash this out?
I think we gravitate to complexity because simplicity is not simple.
[0] This is oversimplified. I'm intending this for communication rather than specifics. Obviously how things compound matters. The numbers are made up but the math isn't. You'll have to read between the lines to determine the complexity that exists for a given situation. I can't be 100% accurate, so let's work together to communicate as best as we can.
Maybe when you're a junior, you like watching "the lights flash and the wheels spin" as Steve Summit used to say, but as you get older, more complexity is more stuff you have to audit, maintain, keep in your head as you extend the system, etc. And that's stuff you have less time and patience for. So you are drawn to solutions that are as simple as you can get away with. Especially since systems that did quite a lot with vastly fewer resources are still within your living memory. If you grew up with an Amiga, and your younger colleagues all started with like Windows XP or something, you remember being productive in an environment that they can't even fathom using.
I know this sounds all very "old man yells at cloud". What can I say. Grug dev only telling fireside stories learned from bitter experience chasing shiny rock.
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
A few things to note here:
1. Given anything more complex than showing a blog post... eventually the complexity of your homebrew vanilla JS will grow until you re-invent React, but unlike React, your implementation hasn't had millions of users ironing out the kinks over well over a decade.
2. using an industry-standard framework makes developers fungible, and that is why companies push so hard for it. You need to develop something because marketing wants it, at best finished yesterday? Hire a freelancer, as long as you keep your code reasonable they won't have much onboarding time, and your own staff can pick up from there.
And that's not just valid for React, it's valid for a bunch more things. Wordpress comes to my mind first and foremost - yes it's PHP of questionable quality and with loads of legacy garbage, but even in the most remote outback village you'll be able to find some college kid doing wordpress stuff for local businesses as a side hustle. Symfony and Laravel for more complex applications. And for anything Java, there's a reason Spring + Tomcat have grown to where they are, it's just the same.
It's just a misfire on foresight. People writing code try to make the computer do most of the work. When they miscalculate the axes along which the machine must evolve it looks like unnecessary complexity. The structure of human interaction dictates the rest: no engineer fitting a piece into a port built for it in software thinks the designer of the software a genius - he thinks himself the genius for having fit it to the port; but every engineer who doesn't find the port thinks the designer an imbecile.
I take issue with the first sentence (but not the idea behind). The problem IS that developers don't build pyramids. They build fanciful architectures and expect them to support pyramids. Complex can never be the bedrock for simple.
Because complexity isn’t formally defined. We don’t have any formal definitions of what it is and as a result we don’t even have any algorithms that can reduce complexity.
Thus because there is no theory, much of software is like art. Just a bunch of arbitrary techniques. That is what OOP is. OOP techniques have no basis in theory or formality yet it masquerades as something formal with big overly complex nomenclature like dependency injection and inversion of control as if any of these techniques mean anything formal.
I digress. Anyway because we don’t have a formal definition of what complexity is we often dont know what direction we are moving in. Is it more complex or less complex? Who knows?
So until someone comes up with a formal definition of what it is we will just be moving in circles.
Complexity is the thing that keeps a certain, very common type of engineer excited. If left to their own devices they will increase the complexity of the solution in such ways that it can just be comfortably managed by themselves (if they have a good run) or just a bit too much so they are struggling all the way (if they have a bad run). The complexity of the problem is more or less irrelevant then.
There are many software products which solve extremely simple problems in very complex ways, sometimes this is called "overengineered". It is what happens, when the simple solution was too boring or when there was a shiny technological hammer and suddenly every problem looked like a nail (think of blockchain products where a simple relational database would have done the trick). This problem exists in hardware as well, but to a much lesser degree, because in hardware every tiny bit you add is cost added to the bill of materials, so hardware engineers have more incentives to keep simple solutions in mind.
To some engineers, them being the only person thar understands the code is a feature, not a bug. That either means they tricked themselves by making the problem appear harder to solve than would be the case (for the own ego), or they tricked others into a co-dependency where the engineer is now needed to understand the solution (for job safety).
One has to admit tho, that some problems are just inherently complex themselves and you have to tackle them at their own level. For example identity managment systems with people from potentially multiple sources where the data shape and quality is out of your control and you still need to reliably create one identity from the data sources. This is a classical: "How hard could it be?"-problem (turns out: very). The solution to that will be complex, because the problems you encounter are. The solution will need to be adaptable because new problems and needs will arise. The solution needs to be maintainable for the same reason. Complex problems + complex requirements = increased complexity in the solution
True mastery in software engineering means the complexity of the solution meets the complexity of the problem, while delivering in all kind of other dimensions like maintainability, legibility, adaptability, security, safety, reliability, ruggedness in changing OS-environments, ease of use, etc.
Many software engineers you will encounter are still in their "write and forget"-stage of their career. They never had to face The Sysamdin that had to deal with their flaming piece of crap software falling apart with every second system update. They have next to no admin experience themselves, that would tell them that good software chugs along for decades in a changing environment.
The problem with complexity in software engineering is that we can just add it. No beancounter breaths down our neck if we add an extra dependency. The problems arising from added complexity are intangible until they aren't, and then it is often too late.
P.S.: I smell chatGPT in some of the phrasing like: "Complexity shouts, “Look at me!”, while simplicity whispers “Did you notice?”."
The desires of certain character types culminate in leadership. Those with this character type who have actual visions that fit withing the symbiotic nature of our reality were about as wanted among their peers as alphas were wanted in human tribes where betas felt treated unfairly and thus ganged up on alphas and their offspring, then establishing fraudulent hierarchies alienated from individual competence, which was compensated by collectively established complexity that served to maintain and uphold the fraudulent hierarchies.
Over time, in IT, engineering and science, this lead to narrower and narrower fields of possibilities, aka probabilities that certain behavioral locks and refused directions and angles will be unlocked (after emerging).
Business psychology, marketing, sales, and culture and psychology are entangled and "envelop" instead of developing. It appears like an evolution but it's an alienation, a contiguous/continuous self-imposed, self-reinforcing isolation from and within a symbiotic, open system.
The complexity forces the reduction of productive points of friction in order to create atomic points of contact with the parent system that minimize even productive and constructive influence. This then enforces rules of self-preservation instead and dictates dogmas of engagement with the rest of the world.
It's the obfuscation of the oldest Ponzi scheme which prefers isolation in singularity rather than a symbiotic evolution. The first who makes it to the patent office vs FOSS. Factory farming for a fancier dinner table. Who cares how much is thrown away, how much energy is wasted and how any of that impacts the chemical cycles of a symbiotic system that kept optimizing for exactly that for billions of years--by design, via self-organization, not necessarily as a hard-coded yield. The world wide web feels similar, btw.
Again, it's a WIP. (I just whipped those paragraphs up, but there's an imaginary pin board with a lot of sticky notes ...)
I think there's a few more reasons that the author doesn't mention.
1) It's actually harder to design things that are simple than complex - to take complex requirements, present and anticipated future, and to see the simple design hiding within. This is where you want senior engineers who have built up this expertise over time. As Mark Twain (but originally Blaise Pascal) once said "If I Had More Time, I Would Have Written a Shorter Letter".
2) There is a big tendency nowadays, not entirely bad, to treat projects as systems integration of whatever pre-existing parts can be had, and these parts themselves may bring complexity since they are made for more general use, and also be "impedance mismatched" since they were never designed to work together, therefore requiring glue and adaptors to make them work. Sometimes it's just better to write something suited to the task at hand than try to force something pre-existing to do something it is over-engineerd for, or not entirely suited for.
3) Resume padding. Software engineers like to use the latest greatest packages and techniques that everyone is talking about, and hiring companies are asking for, even if they are not that well suited to the project at hand. Sure, with some effort and extra code you may be able to incorporate some sexy new tech into your project, but it may be to the detriment of the project.
It's actually harder to design things that are simple than complex
This. In fact it’s often harder to even figure out what simple is until you actually try a bunch of things, and current corporate software methodologies don’t allow for iteration and experimentation to figure it out; you get one shot before the software’s even exists yet.
At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.
> At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.
"Quickly" is relative. If you can produce software quickly, that'll become the expected speed, so it's no longer treated as quickly and we will get back to the same situation.
I’m not suggesting that you vibe code the solution; I’m saying you vibe code the prototype.
Rapid prototyping is certainly a good use case for AI, but I don't see it really working for larger work projects where design complexity make be an issue.
Certainly considering how all the parts interact is part of brainstorming alternate system designs, but I think high level architecture / project-decomposition (design) has to occur before prototyping (coding) would be applicable.
Design/architecture by vibe coding doesn't sound good, but using AI to brainstorm different architectures (before any coding begins) might be useful.
While I do think there is some value to vibe coding, spending more time thinking about the final product is just as necessary and often lets you gleefully cut away many gordian knots.
Quickly exploring the implementation details is nice, but it's rare if they ever get in the way. What really gets in the way is shitty planning.
I like this - Hubert Humphrey (VP US) was asked how long it would take him to prepare a 15 minute talk: "one week". Asked how long to prepare a two hour talk? "I am ready right now".
I'm not entirely clear what the argument being made is. Simple tools are simple, sure.
But there is an awful lot of complexity in otherwise simple things. Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I think, often times, people mistake the results of something from the tools that went into it. Such that it can be tempting to think that simple looking creations were made with simple tools. As often, the opposite is the case. It takes complicated tools to build something that looks simple.
Maybe the argument was that you put more effort and work into what you are building than you do that which you use to build it? I think that is largely fair.
That is actually somewhat in focus when discussing a pen versus the "penzilla." For one, building a pen is a surprisingly difficult thing to do. Especially at scale. For two, people rarely want to have a pen for the sake of owning a pen. Instead, you want to write something.
There's a lot of old sayings that capture this sentiment. "Simplicity is complexity resolved" (Brancusi), "Good design is invisible) (???), "The best craftsman leaves no trace." (Chinese Proverb??).
My favorite is "Sprezzatura"[0]. The act of making something look simple. IME, the mark of a true expert is they make their work look trivial. As if anyone could do it. It's bittersweet that this is the reality, because we seem to have fooled ourselves into thinking things are as simple as it looks ("pun" intended). It's a dangerous trap. Over estimating difficulty will prevent us from trying, but underestimating will make us foolishly spin our wheels. But I think we've built a system where we just normalize wheel spinning. It's true, most wheels are made for spinning. But if they're freely spinning in the air then your car is going nowhere.
[0] https://en.wikipedia.org/wiki/Sprezzatura
Thx
> Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I would assume the power drill was created first if you include human powered drills, screws came much later than pretty much every other kind of simple machine, and until machine tools were invented, screws as fasteners didn’t really exist outside of specialized applications. They were used for presses and applying force.
John Henry was competing against a steam powered rock drill in the folk tale about him.
If you define power tools as tools driven by electric motors, I would still guess that the drill came before the driver, as rivets seem to be more popular in the steam engine to electric transition period than bolts or screws were.
Slightly confusing things is the fact that a modern drill is almost always a driver too, unless it’s a specific kind of drill like a hammer drill or core drill. Confusing things even more, there are drill bits that are meant to be used with an impact driver, a tool that is used to tighten or loosen fasteners.
As for which is simpler, drill vs (impact) driver, it’s hard to say. A drill has a clutch, and an impact driver has a spring mechanism that applies rotational force when the motor is at its limit. I’d say both are fairly complex, the impact driver is probably a bit more complex than a drill.
I’m curious about the development and history of power tools but it can be difficult to find information about it.
Your progression of "confusing things" happening several times is exactly what I was hoping to elicit. And is why I think it is a bit of a red herring to ask which is simpler.
Love this kind of comment, where one commenter poses a thought experiment about something I'm unfamiliar with, another commenter explains it in full seriousness.
Here's semi related talk about simple/complex and easy/hard [1].
[1] "Simple Made Easy" - Rich Hickey (2011) https://news.ycombinator.com/item?id=23905051
Heh, I'm pretty sure Rich Hickey is a fan of React and the Clojure community uses it heavily with Clojurescript.
Rich Hickey had nothing to do with it. He did put a lot of the initial work to get Clojurescript up and running but for many years the majority of cljs maintenance and shepherding was done by David Nolan. Not sure now; I've been out of the loop for years.
The Clojurescript community was the first group adoption of React outside Facebook (early on they had community news blog post and mentioned it) but that because the React rendering model fit the Clojure data model. I was active in the NYC Clojure meetup at the time (Rich was from upstate and would only come in for big announcements, and David was local) and we had 4 or 5 months where there was active discussion among the web devs after the talk on how to make cljs actually work. My memory is Brandon Bloom is the one who made the React connection. David picked up the idea and promoted it to the wider community.
Thank you for the lore :)
I thought I could recall some post/article where Rich Hickey said something positive about React but I can't find it. Maybe I made it up in my head idk.
I think this is not the point of the argument. Power driver solves a problem, but not everyone has that problem. Some jobs just need a drill.
The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
> The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
I think this argument isn't valid. The problem that React solves is creating reactive user interfaces. React is trivial to use in it's happy path. The tool's complexity is a red herring because using the tool is trivial and effortless.
To me, this argument is based on specious reasoning. Take for example vending machines. They are trivial to use: pick a product, pay, see it drop and pick up your item. It's dead simple. Does it make any sense to whine that buying items from an automated system is a problem not everyone has, and that the vending machine is far more complex than a seller behind a counter? No. What makes sense is the complexity from the user's perspective, and what effort it requires them to achieve the goals they set forth to achieve. And React makes it trivially easy to put together highly performant reactive web apps.
> The problem that React solves is creating reactive user interfaces
The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.
This is potentially not the same problem that you are envisioning there, and it tends to put rather different constraints on the solution.
> The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.
Nonsense. React's selling points have nothing to do with repo structure or the number of engineers working on a project.
If you ever used React at all, you would understand that updating the entire state of the appocation after receiving any input is a non-trivial feature that React turned into a trivially solved problem.
On top of that, React adds modularity and composability.
I wonder if you're criticizing something you have absolutely no experience in.
why it does things the way it does is relevant - the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)
If you were building a state update layer without Facebook’s constraint of extreme scale, it might look rather different
(Also, I’m not criticising react - it solves a variety of problems well. If they are the same problems you have, great)
> why it does things the way it does is relevant -
Yes. React automatically detects the minimum set of changes to a DOM that is required to update it's state, and manages how those updates are applied to maximize performance. It transparently handles both app state changes, and basic changes to views triggered by updates to models.
This is a problem everyone in webdev has. Everyone.
Did you saw any of the comments here on how a little JavaScript allows people to update the DOM?
> the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)
No.
The reason why Facebook had problems with state management and modularity was because Facebook had to maintain websites.
The reason why Facebook developed React was because they had clever people who identified the problem and were given resources to work on a way to turn a hard problem they experienced into a trivially solvable problem.
Companies, big and small, develop their own tooling and infrastructure to improve efficiency, and they do it all the time.
Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
> people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
No, they do it because it's simpler.
> They do it because someone else told them so.
Alternatively, they do it because if you are holding a React, everything looks like it should be implemented using a React. While the finished product might be more complex than needed, it is less complex for them, because they have used a tool they understand well.
Maybe they do it because they like React? :)
> Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
No, not really. There is more to picking up a tool than some rando's simplistic drive-by judgement. For example, say you have a React SPA managed by a team which built and manage their whole platform, from the CICD pipelines to the hosting solution. All your infrastructure was built around providing a React app and it's backing services. You are then suddenly faced with a need to implement a feature where a user after clicking on a link navigates to a page that just shows static text. Now think. If you implement that page with React then that's a one-point task. Just create a component, fill it with text, post a PR, done. What level of effort does it take you to implement that with another technology? If you go with the simplistic take that plain HTML is better, now you need to set aside time to sort out support for styling, sort out where and how to deploy those assets, work on a process to automate the deployment, etc etc. Now your simplistic drive for simplicity turned into something between a week and a month's worth of work requiring infrastructure changes and adapting deployment strategies, all of this requiring not-so-trivial QA and testing work.
What problems did you solved? Can you describe your system as simpler, and keep a straight face?
You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.
> You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.
Not really, the article is about a belief some other approach would be preferable based on superficial and specious reasoning.
My example proved that this kind of superficial and simplistic analysis fails to account for critical aspects which are key to explain why a decision was made.
This doesn't go away by complaining that I refuted your point while I could easily not refute it.
The whole argument is silly, if you think about it. What could possibly possess anyone to believe they are the only ones who know better and everyone else in the world who disagrees is stupid and doesn't know what they are doing?
> The article is about the latter.
And yet fails to provide a single example.
I'd certainly be interested in seeing what kind of websites this guy produces that are written in "javascript". If any. And it is rather damning that his own website that host the blog is written in react, not "javascript".
The argument is valid and doesn't need over analyzing.
Using react for simple simple things makes it not simple.
> The argument is valid and doesn't need over analyzing.
No, it isn't. A big part in your failure to understand the problem is your refusal to look at what you're doing, which you try to dismiss as "over analyzing". As if reaching the conclusion that a simplistic proposal brings unacceptable tradeoffs means you are looking where you shouldn't.
> Using react for simple simple things makes it not simple.
Did you actually took any time to think through that assertion? I don't think so. For starters, you didn't even stopped to think why React is used at all. Why was that?
Right, my point was more that thinking you can guess the simplicity of a solution based on the complexity of the tools used to build it is a bit misleading. If only because most simple tools are far more complicated than that allows.
Similarly, I would argue that using complex tools to build something generally results in less complicated outcomes. Our computers are basically evidence of that.
Yes, the modern world is a confusing thing.
Difficulty of use and reliability don't seem to have any relation to complexity on mass-distributed products. Costs depend almost exclusively on scale, and not on inherent properties.
But why would I want to use a screwdriver when I could use my power drill? Like sure, the screwdriver works, but it's more effort and slower...
Actually there's lots of times I want to use my hand driven driver rather than a motorized one.
I agree with the other comment mentioning analogies have their limits. Are we going to pick them apart just so we can avoid listening? Communication is lossy. Are we having a conversation or just trying to win a game of our own design?
I add that because how I interpreted taeric's point of a drill and a driver is just a variation of "apples and oranges." You can concentrate on how they're both round fruit or you can recognize there's differences. I mean walk into any machine shop or go to your uncle that likes to make things and have them explain why they have so many wrenches of the same size but in different styles. Often the subtle differences are the most important part. Hell, how many people even know what those numbers do on the power drill? Making use of them really ups your game. Same with adjusting the power level on your microwave. Yet I rarely see people use these things which are highly effective and help avoid many common mistakes.
I wasn't trying to pick the analogy apart, I thought it was quite a good one and was running with it. I think it breaks apart though when you start talking about minor differences in wrenches though - it's not like the difference between Vue and Solid will make a significant difference when building an app. But between a screwdriver (jQuery) and a power drill (js framework), that can be very significant.
Analogies have their limits. That being said, there is always a learning curve. Imagine a situation you want your 5 year old to assist you, but you don't want to teach them how to safely use a power drill.
Yeah for sure. Sometimes my drill is not charged and it's easier to grab a screwdriver and give it a few quick turns (https://benton.codes/blackberry), or maybe I can't fit the drill in some space.
But normally I'll use the drill even though it's overkill, because I got other stuff to do :P
Sometimes torque is a bad thing.
I see you've never seen or dealt with a head blown out of a fastener. A drill has basically no feel, and things escalate quickly especially for marginal fasteners.
and perhaps you've never used a good motorized screwdriver with torque control.
Needless complexity! /s An excellent example.
Cordless drills for driving screws have clutches. Also, you have to always make sure to use the correct bit. It doesn't matter whether you use a screwdriver or not, you'll strip the screw with the wrong bit either way.
The argument is that certain tools introduce complexity into a project by the mere act of using them. A power drill has many more knobs and features that the user must be aware of than, say, a screwdriver. Sometimes those features are required, but often developers will gravitate towards such tools even when they're not.
In software development this applies not just to external tools, but to abstractions in general. We might be tempted to create or depend on an abstraction that solves many problems in a generic way, when in reality this could be avoided. The appeal is to reject this temptation whenever possible.
Simplicity is an amorphous quality without a clear path towards it. It's often debatable whether a system is simple or complex, given that most software is built on extremely complex machinery we take for granted. But the least we can do is to be mindful of practices that lead to a net increase of complexity, use critical thinking instead of blindly following trends, and, sometimes, take the more difficult road for the sake of preserving simplicity.
[dead]
[dead]
React piles concepts into your mental backpack: rendering models, hooks, state libraries, routing, and a build pipeline. ... The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework
Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".
The whole reason frameworks exist is to _reduce_ the mental backpack by using something that has solved the same problems in the same orderly way.
I'd argue the whole point of React is to enable the modularization of components written in Javascript.
I realized as soon as 1997 that if I wrote some component in Javascript I wanted to stick into a web page I might want to stick two or three of those into a web page and to do that I have to keep the state for those separate, be able to reference the form elements (didn't have access to DOM elements!) with a unique name, etc.
React goes past that and lets you nest components into other components. In some point that's "managing complexity" and not "introducing complexity", except for the fact that when you can easily incorporate 35 third party components into your application that is 35 components each of which introduces its own complexity of one kind or another -- some of the complexity of "modern Javascript" is the complexity of the build system and the framework, but the build system and framework system let you build bigger systems that have bigger problems.
Software is a Jeavons paradox. When you use a library (time efficiency) you are compelled to add more features (complexity)
That's not really an accurate statement of Jeavon's Paradox. In this case, it would be "when everyone has better tools, people expect better websites."
It insists upon itself.
> Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".
The ultimate step into irony is reaching a point where, to justify their approach, they claim that it's ok to spend all this time reinventing JavaScript wheels because all this "sprinkle-on" JavaScript can be packaged and reused in other projects.
I'm glad they at least had the bravery to provide a concrete example of what they mean by "complexity". Clearly their example of "React = complex" vs "JavaScript = simple" is actually a fairly controversial take. Does "simple" mean "better", if not, I think we should be chasing the latter.
I'm not even sure it's a controversial take, more of react devs (don't worry, myself included) feeling called out and getting defensive instead of trying to understand something simple.
Ask a biologist or ML enthusiast; complexity is the natural outcome of a period of mutation/selection. It's a mistake to criticise the result on the grounds of said complexity, I think - rather ask what environment the complexity evolved to "survive" in.
It's boring common sense but don't take a bromeliad into the desert.
My belief is that all codebases that live long enough will develop this level of complexity with time. The only exceptions imo are where the codebase solves a very particular, fixed problem, e.g. a library for A* pathfinding or whatever. But maybe not even then.
I think this covers nicely discussion about the HTML, CSS, JS and browsers complexity from other thread.
We have a bit of messy complex system that we can run cross platform applications including mobile.
But it was only one that could survive corporate greed and shenanigans where all other UI toolkits and frameworks are limited in one way or the other or entirely dead.
People nag about the complexity and messiness but there is no other surviving alternative.
Often times, as bad as it sounds, the business value is forgotten by developers who criticize these systems. Like these systems are already in place, it would be an unrealistic undertaking to exchange them with "less complex" systems. Businesses unfortunately have to make money, rebuilding something they heavily rely on is not something they can just do (Part of why so many corps are vendorlocked by SAP). Also, where are the less complex systems? I did not see anything as flexible and easy as web tech. Even though it pains me how unsafe it is.
It's Conway's Law. Companies ship their orgs, and the people shaping the org are not approaching it with CS fundamentals. This means they will slice and dice the domain according to some arbitrary, probably business driven, criteria. These become teams, and the teams then add code with boundaries around these arbitrary divisions. This adds a ton of complexity and entropy. React is basically designed around this. React favors flexibility and "developer experience" at the cost of performance and complexity.
I like my colleague Simon Morris's observation about software complexity:
> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility.
> Build pyramids if you must, but build them like the Egyptians did: with a clear purpose
For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids? Maybe the rest of this will fall into place for me when I understand that.
To build a tomb. Not a shrine, not a place of worship, not a functional structure. Not something that could be repaired or repurposed. A tomb and nothing else.
A purposeless pyramid would get bogged down with plumbing and fountains and extra passageways and observation decks and on and on and on. It would have been impossible to build.
> extra passageways
They 100% had these.
There seems to be a yet-explored "big void" in the Pyramid of Gaza, found using "Muon tomography":
https://en.wikipedia.org/wiki/ScanPyramids#ScanPyramids_Big_...
https://en.wikipedia.org/wiki/Muon_tomography
i mean there where usually temples around it with cults
IIRC, their society depended on it. During peacetime, it was a major economic engine paid for from the royal treasury, with the work starting as soon as a new pharaoh ascended the throne, and the labor provided steady work when agricultural activity stopped due to Nile flooding. Of course, it's only in hindsight with our modern understanding of economics that we can see how such an activity at face value not important to any basic survival need was in fact a key piece of the economic fabric.
> The Roman writer Pliny the Elder, writing in the first century AD, argued that the Great Pyramid had been raised, either "to prevent the lower classes from remaining unoccupied", or as a measure to prevent the pharaoh's riches from falling into the hands of his rivals or successors.
This was the Pliny view.
Aka, it was a jobs program.
It was a Keynesian anti-cyclic wealth distribution program.
The jobs did come and go as necessary to maintain stability. It was reasonably well paid, from money collected taxing the luckiest farmers at the good times, stored as a community project.
It's really impressive how the Egyptians created this kind of organization and maintained it for thousands of years, when no government seems to be able to maintain something similar for a decade today.
If only our current leaders could have the vision to build robust infrastructure
Reliable secure high-persistence storage.
eg: The Stone Tape https://en.wikipedia.org/wiki/The_Stone_Tape
some side effects may occur
You think you're getting into the afterlife in a measly $2000 casket? Nah, the dead pharaohs had to ride in style.
> For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids?
For them to be able to properly descend to and navigate the afterlife of course. This is why society today is so broken, all we get for our afterlife is a shitty urn and some bland sandwiches.
Ah yes, because we are all Pharoah
I think more than anything else the pyramids were built to stand the test of time.
Regardless of any other objectives, the further that humans progressed into the future, the more this one purpose eclipsed all others.
Until by now what means most is that almost nothing else has come very close to this long-lasting purpose at all.
Its because "reality has a surprising amount of detail". It is actually the rare occurrence where a simple solution solves a complex problem. I link an excellent article that has been posted on HN multiple times, that explains exactly this.[1] (not mine)
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
This is very apparent in my work right now, as well as "all models are wrong, some models are useful".
I'm parsing some "simple" CSVs into a DB, but I have to keep the concrete representation intact for another purpose. The DB format will be similar to the CSV format, but can't be quite the same. I would've figured this would take a day or two (I've written many parsers before), but the amount of details I have to consider has lead me to circle back to this problem for a long time.
If we used ascii delimited values none of this would be a problem. The amount of effort spent on csv must be close to a million man years and all because we want to edit the files with a text editor without a special mode.
The files are CSV-adjacent, I should say. The issue here isn't the delimiter in fact, it's the fact that the format differs slightly between files, even within the same project. That, and the mismatch with the SQL DB format I want.
With the predefined ascii delimiters there is no difference between formats, because you can't choose anything but the dimiters ascii gives you.
After rereading the post I realize that the op was talking about the schema of the files rather than the adhoc nature of trying to decode escape characters.
Ascii delimiters will not save you there.
Not sure if it's just me, as I'm relatively new to the field, but I notice a surprising amount of people assume that the details in programming have already been made intuitive to them, and they use this "experience" to push ideas that are at odds with other domain specific details. To me, maybe this is what the author means by "stuck"?
At any rate, great read.
But software is not "reality" in that sense. For example, software is deterministic and reproducible (if you dont fuck that up).
I relate more to the comment in GP's article:
> If you’re a programmer, you might think that the fiddliness of programming is a special feature of programming, but really it’s that everything is fiddly, but you only notice the fiddliness when you’re new, and in programming you do new things more often.
Paradoxically in SW development complex things often appear because it's easier (simpler) to 'just add this check here' instead of rethinking (and remaking) previous solution with updated understanding.
'We'll fix this later, now just make it work'
It takes more effort to make things simple than to make them complex.
> Paradoxically in SW development complex things often appear because it's easier (simpler) to 'just add this check here' instead of rethinking (and remaking) previous solution with updated understanding.
I think the issue is actually deeper than that. To start off, the definition of complexity that's used is often partial and incomplete, leaving out entire domains where complexity manifests itself.
So it's often easy to make swooping statements about what is complex and what is simple, because what appears to be simple is actually offloading the bulk of the complexity somewhere else.
Take for example CICD pipelines. They can be very complete, thorough and complex. You can shave off part of that complexity by doing manual work. Do you get a simpler system if you replace a pipeline with manual work? No, you get a system that's far more complex, unreliable, and brittle. So how come no system is more complex than introducing a system? Where does the complexity lie?
I don't think that's paradoxically, that's just the reality that changing a little thing is easier then considering all cases the code has to handle and figure out a solution which addresses all
What's paradoxically imo is that often - when someone does decide to remake it in their vision... It's usually isn't improved - heck it's often even more complicated after the refactor.
The other day there was a guy here on being mad about my program/code being simple.
bro, like what? if i can make living from simple things why will i complicate it? It just seems some people complicate things to justify their pay which later becomes difficult for their organization to maintain.
No wonder the guy was not accepted at FAANG where code maintainability is utmost priority.
Lots of engineering disciplines enjoy complexity. It is challenging, and doing challenging things feels like an accomplishment, or demonstration of skill. I think software gets away with higher levels of complexity than I typically see in other engineer disciplines because it has a lower negative impact from the perspective of the business or the end customer. In auto manufacturing, for instance, complexity not only increases r&d costs, it also increases performance unit costs, and typically reduces reliability and maintenance costs (both of which are usually visible to end users). In software, complexity may appear to reduce r&d costs by reusing code in suboptimal ways, but the end effect is marginal slower, marginally higher binary size, and higher maintenance costs, but the end user doesn’t really ever see the direct maintenance cost, just a subscription price or support contract.
Imagine reusing an entire physical assembly for only one of its functions (eg a microwave to get a clock) this is the sort of thing we do in software all the time, but would immediately fall apart in other disciplines.
We can't see software.
You can see if a motherboard has twice the necessary components, or if a robot arm just looks wrong, but if your algorithm to process 1000 records takes a thousand times longer than it should (but still finishes in 100 milliseconds) no one notices.
Until it has to process stuff in real-time that is.
A robot arm is exactly the place you see software acting up. If your algorithm is consistently slow it's fine, the moment it's inconsistent things dont line up and problems happen.
All that build-up, only to culminate in a slight dig at react?
> React piles concepts into your mental backpack: rendering models, hooks, state libraries, routing, and a build pipeline. Say no to it, and suddenly you’re the “neckbeard stuck in the ’90s,” outside the cool-kids club.
Out of the list of the piled concepts, only 'hooks' would be react-specific. The rest are the concepts that a front-end developer will need to think about anyway if he builds a standalone client. If the client is built using non-web-standard languages; or even if static file names need to be stamped with hashes for proper caching, developer has to think of a build pipeline. If the client is decoupled from the server, developer has to think of routing. If things happen on the page in response to user interaction, developer has to think of rendering and of client-side state.
React isn't guilty of any of this. There are plenty of things it is guilty of; but these aren't the ones.
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed
Is it simple though? From my experience, apps written with "sprinkles" tend to become very complex very quickly. Unless the author means something else by "complexity".
I see a coming soon page one time that had a background image, a logo in the middle and 5 lines of text. That was the entire thing. Wondering why it took so long to load I view the source. 30 js files, 5 css, a hundred html tags with 10 classes each.
Wondering the same visiting a web shop I found a seemingly infinite amount of js. Digging a bit deeper I ended up getting lost in some enormous library for rendering unicode smiles with data uri's. It seemed like a good idea as each page was already making many hundreds of requests. If they add 100 smiles to a product description it probably never loads.
In my experience you can avoid things getting very complex by just refusing to add new "features". If that is out of your control it isn't your fault. Build them the pyramid!
Elsewhere on HN https://iaziz786.com/blog/boring-work-needs-tension/
Complexity adds tension.
Bored Software developers add complexity to make their jobs more interesting is my take.
Why do some folks love assuming walking backwards to the past is the only reasonable path?
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
Having grown up doing webdev at its emergence, those were not glorious years.
Even as a solo developer or part of a small team, it was hard as hell to have a perfect mental image of the app at all times, to understand all the combinatorial possibilities of what state your app is in now and what state you want to head to next.
Trying to forever update retained state is hard as hell, full of incredible opportunity for memory leaks, and created some super weird behaviors.
Even more so, "just write the basic code" doesn't scale. It's not a system that an org can follow. Folks will come and go, each going totally different directions. I don't know how to stress how immature and insane this sounds.
But folks love trashing that which is popular. To declare oneself the only sane mind amid a sea of madness.
I really do hope we see some post-React eras dawn, see more, that this isn't it, on and on. But I respect like hell the switch from a retained mode form of webdev to an immediate mode one. It doesn't just skip by so many really bad failure modes, it's often far far faster than the poor incomplete hacked out vanilla.js solution your org ended up with. I want us to change to move to not be stuck here. But to see where we are as unnecessary complexity, to invent fantastic degrading tales about the weak souls of men for getting us here: this is truly the behavior imo of lowlifes, of those spreading propoganda to spread the thinnest false confidence of hatred and disdain against the world.
Things are complex and that's ok. We are learning. The way out in onwards not idolizing a concocted naive pastoralized past.
This comment is on point, so all I'll add is this:
> The way out is onwards not idolizing a concocted naive pastoralized past.
Ah, the noble JavaScript savage of 1999 - so in tune with his environment, his nose twitching in perplexed confusion as the unfamiliar scent of DHTML wafts past.
Unconcerned with a future that he cannot possibly imagine, he launches Dreamweaver and begins coding, secure in the knowledge that the more things change, the more they stay the same.
You're right that immediate mode is great and makes life so much easier but for most use cases, React is very much a "retained mode" framework. If all of the valuable state in your app has its source of truth on the server (majority of apps), then retaining any of it in React state soup is unnecessary complexity.
People like to bring up how terrible it was to do vanilla.js in the old days but completely ignore that we are not, in fact, still in the old days. Native browser APIs are so much more powerful now and a ton of the pain that React was made to solve is even now handled declaratively with some simple HTML and CSS. No hacked out JS required.
Yes the 90s and 00s were rough for js, especially because of where JS and browsers were at, and also our collective knowledge.
However also it was much nicer in many ways -- we weren't trying to make insane single-page-apps like today.
The irony is that we have all of these powerful frameworks, but somehow they seem to mostly make worse/slower websites than this silly 0-javascript orange site we're on right now.
It's a progression.
To achieve simplicity, you must first outline the complex process, identify commonalities, and then simplify.
You can't reach simplicity without going through and organizing our messy, internal thoughts.
Yeah this exactly.
Simplicity is borne out of messy, complex stuff. That one then has to do the work of removing the stuff that doesnt matter / rethinking how stuff fits together.
Most people dont really have the mental energy or discipline to go through this process, so by on large, complexity exists in the world.
That an entire population wide brush ya got there. Not true at all. In many many cases, an initial implementation that is supposed to be figuring out the problem is never revised, just shipped. All these "complex code bases" are premature code that will never see maturity, just patches by an ever increasing population that understands the problem less.
Related submissions/discussions:
Organizing complexity is the most important skill in software development: https://news.ycombinator.com/item?id=9757892
System design and the cost of architectural complexity: https://news.ycombinator.com/item?id=35470905
Software Complexity Is Killing Us: https://news.ycombinator.com/item?id=16260320
Simplicity is an advantage but sadly complexity sells better: https://news.ycombinator.com/item?id=40266464
Do We Worship Complexity? https://news.ycombinator.com/item?id=18230827
Fighting Complexity in Software Development: https://news.ycombinator.com/item?id=20357203
Complexity fills the space it's given: https://news.ycombinator.com/item?id=40704267
> Sell me this pen:
> What? You don’t know how? Okay, instead, sell me this Penzilla - a pen that can erase, write in different colors, play music, dial 911, act as a radio antenna, and even help you cheat on your homework.
Anecdotally, I read somewhere (and agree) that the reasoning behind the "sell me this pen" question is to quickly identify whether someone has the most basic skill necessary to become a decent salesperson: asking questions about need and listening to the answers.
I'm guessing the author of this post does not work in sales (hardly a bad thing) because "selling a pen" by listing all the excellent features of the pen and why it's better than any other pen on the market is exactly, according to the theory, what you should not do.
Do you use pens? What kind of pens do you like? What bothers you about the pen you've got? Well, if this pen doesn't have any of those issues, why not just buy a hundred of them right now and stop wasting mental energy on what pens to buy for the next ten years?
Weird take: rather the opposite in my team. We look for the simpler solutions due to maintenance burden. Also, we actually deal with very complex tech; virtualization. Our whole premise is to create tooling for convenience, which therefore involves abstractions.
Some complexity in that case is needed, but its aim is to provide a cleaner/simpler access, which is often opinionated, limited to the purpose we have: deployment of development tools for containers.
If you want to experiment, show off as the article implies, start a hobby project.
Edit: removed some fat-fingered typos when I wrote this on a phone
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
I worked with a front-end developer (React) who needed help integrating with a payment processor. I looked at the docs and hopped on a video call with them to get them unblocked. I ended up having to explain how to POST hidden inputs via an HTML form to them, and their reply was something along the lines of "Oh, HTML is obsolete." They didn't understand the basics because they only new React.
I think complexity used to sell (real architects used abstract factory factories). Today, simplicity sells and while far better I think it can lead people to do dumb things sometimes. There isn't any problem with simplicity of course but rather what people define simplicity to mean. Sometimes it means things like "let's write our own database", because it is "simpler".
Right now, "simple" is meant to translate as "good" for the reader and whatever writer wants it to mean. I'm glad, at least, that the article provides an example (React vs plain Javascript). I don't know for sure but I suspect there are at least some valid arguments for using React vs just grabbing dom elements in Javascript.
I don't think we're gravitating towards complexity. It's much simpler:
1. We add more functionality to the base of what exists (e.g. HTML). More and more individual features. (e.g. selecting things in the DOM, animations, effects, interactions, tracking state)
2. At some point someone takes all the patterns in the latest wave of functionality and writes a library for them. Library is widely lauded or adopted (see jquery, React).
3. We think of new features building on top what is now the new norm, it's now table stakes. Rinse and repeat.
This is a common pattern in engineering, for example writing new entries to a DB, then at some point going back and compacting.
While I don't doubt that trying to "show off" or "job security" is a reason, I think another big one is because too many developers have no knowledge of the low-level basics to even consider that things could be simpler, having only been exposed to overengineered code and indoctrinated in the belief of abstractions as the ultimate panacea. To relate to the example of React and JS in the article, there are likely many web developers now who have never written a single plain HTML page and always started with the minimum React SPA, so they don't realise the former is even possible.
Status and the appearance of being smart.
I have a bee in my bonnet about this software complexity issue. Perhaps it takes large amounts of humility to accept that your job is fairly mundane, and only needs simple code to get the job done? I mean: who wants to turn spanners on a Toyota when you can imagine you're working for NASA, and introduce fascinating new paradigms to your work, that ultimately add complexity. I suspect that's why i've joined so many teams that have tied themselves up in knots of un-grok-able indirection. Another theory I have is that people encounter bad code, and misdiagnose it, identifying the (wrong) solution as needing a big complex architecture.
I think it’s actually easier to make code more complex than it is to identify simple elegant solutions that will continue to work as the code expands.
There you go. Instead: compression, efficiency and speed are better traits of intelligence in software engineers building these systems and being aware of trade-offs.
Rather than building rube goldberg contraptions and not only it is difficult to refactor them but can kill the entire business if the maintenance costs continue to increase.
Gotta pad your CV/promo packet somehow.
It's pure dopamine, from the process, for me. "Eureka!" is a hell of a drug.
If you really want to work with the most pretentious, attention-seeking, optics-loving people, work in robotics. God dammit, how I love the field, but most people there are insufferable.
The reason why the pyramids worked is because they never had to CHANGE.
Changing realities drives complexity, and the more chaotic those changes, the quicker the complexities pile up.
If you look closely at the pyramids, you can see that the later ones were much more solidly built than the former, having learned from past mistakes. But the reality around them hadn't changed (and still hasn't after thousands of years), so every iteration became more and more efficient since they were building anew each time.
Not so with software! Every time you iterate to make something more efficient, every time you're forced to react to a changed reality or imprecise model or failed assumption, it still has to fit into the overall system and keep working somehow. And that could mean working with a system that has a fundamental assumption that doesn't even hold true anymore, and would require so much work to fix the assumption that it's not worth the cost to fix.
The main benefit of software systems is that they can be reprogrammed to deal with changing reality. The downside is that these systems operate on entropy. That's the trade-off.
We like to scoff at old, "crusty" systems and the morons who didn't know what they were doing, but this is the fate of all software. The difference comes from your stewardship over the project, minimizing the impact of the entropy that constantly assaults what you've built. The Linux kernel is a good example.
The pyramids analogy may lead to a different line of reasoning: not only they look useless (making all the effort and complexity put into those unnecessary), but at least Aristotle claimed (not sure how accurately though) that they are made to keep people in poverty and occupied, in order to preserve a tyranny. Akin to the modern concept of "bullshit jobs".
The list of accidental complexity sources looks rather short. Off the top of my head, I can think of CV-driven development, of developers not being aware of basic tools, reaching for heavy and marketed ones instead, of awkward regulations pushing to silly solutions, of simple incompetence, of the NIH syndrome (or does that qualify as "creative temptation"?). The "Legacy systems and technical debt" point is applicable to newly developed systems with poor planning and strict deadlines as well. And then there are all the arguments about what is simple and elegant (or not) in the first place.
I read once that organisation is in favor of entropy. When a system organises itself it "consumes" more energy. And I think complexity could be seen as a sort of organisation. So in this case complexity is just the tendency to participate in time.
An example being the increased inefficiency, and rate of fuel consumption of aircraft with quadratic air resistance.
Some types of complexity have well formed mathematical definitions. Cyclomatic, time and space, kolmogorov, etc.
Something that's complex to the intellect is ill defined. I suspect it can be defined, but it's very highly dimensional. That is there is no scalar complexity number that can be used to compare items directly, and instead you may have two solutions of equal complexity but in different (and otherwise incomparable) axis.
The issue we have today is that we have no academic way to approach complexity so people just sort of develop an intuition for the subsets that they encounter and get bitten by.
However, because they have only a partial picture, they end up simplifying the complexity they do understand in a way that increases the complexity that they do not understand (at least until it's too late for the project).
Gravitating toward complexity is inexorable because simpler systems are prerequisites of more complex systems. We see the same thing in evolution--it's not inherently directed, except in this sense of prerequisites. Systems can go from complex to simple (e.g., viruses), but complex systems cannot leap into existence -- see https://www.tedcloak.com/uploads/4/5/3/7/45374411/gregory_-_... -- they appear over time, via accretion. Scientific knowledge largely works the same way -- there are prerequisites. e.g., Einstein's concepts were seeded by the Lorentz equations, and of course Newtonian physics.
Of course biologically evolved systems don't occur unless there's some fitness function they satisfy. Well, complex software also provides desired functionality--sometimes the desire is just a result of marketing, but often it's due to real needs.
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.
Phenomenal post that reads like a developer’s version of my IT rant on the same issue: stop needlessly overcomplicating things for the sake of complexity alone.
The difference being that, at least in my side of the technical sandbox, it’s often along the lines of dissuading someone from propping up a K8s cluster for what’s better suited to a single VM, or stop shoehorning multiple overlapping agents onto endpoints instead of properly utilizing what you already paid for elsewhere, or stop carving out exceptions to policies and procedures that make support and maintenance exponentially more complex.
Complexity is a bug, not a feature, at least for 99% of use cases. The problem is that everyone seemingly thinks they’re the 1% that justifies said complexity.
Managed Kubernetes is easier than VM. It provides high-level concepts, allowing you to deploy programs with less friction. It does it at a cost of complicated programs running below, but you won't find simple things. Modern CPU alone is insanely complicated machine. You can achieve simplicity by building your product on complicated foundations and Kubernetes is one of these foundations.
Another example of complexity is compiler. Even assembly compiler brings a lot of complexity for modern software. Yesterday I wrote dumb empty program with 3 assembly instructions to syscall exit. To link that program, I had to deal with the following sections: .rela.dyn, .rela.plt, .plt, .text, .note.gnu.property, .got, .got.plt, .data, .bss. Of those sections, only .text contained useful data, but GNU software generates them all and wanted my linker script to handle them all. I spent few days researching about it and I still have very little idea what's happening there. And that's the lowest layer possible: x86_64 assembly. For something as simple as C language, it'll be magnitudes more complex, with plethora of C standards, GNU extensions, compiler optimisations, hundreds of compiler flags.
IT is complicated and there's nowhere to run. You can only choose some building blocks, pretend that they're fundamental and simple, and build upon them. Most C programmers probably ignore all those sections, have no idea what they do and just let default linker scripts do their work. But the sections are there and complexity is there, it's just hidden below layer you usually look at.
This is a perennial problem, see The Mythical Man Month
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Or if you wan to have more fun read Systemantics
https://en.wikipedia.org/wiki/Systemantics
Bikes used to be fairly standardized to where you could do most builds and maintenance at home . Now there are hundreds of subcategories , parts are bespoke to the bike , and standards have all been obliterated. Duty cycles are very short . Brakes , BB , headsets , bars , axles , cassettes , freewheels each have half a dozen formats . Bikes are practically disposable. Costs are up over 10 years and quality on many aspects has declined .
There are hundreds of boutique brands and almost none are making any money. No one sensibly pays msrp you can find bikes 60% off easily.
When you think about productivity , in terms of how much utility can be produced by one person, it’s obviously declining . We have more tools, but the bulk of the effort has gone into getting attention rather than providing utility . Even the product development is more about marketing than utility
I think it may come down to the question of:
"can anything do everything?"
Meaning, as we invent tools that showcase a novel use, further ideas for how that tool can be used start coming to mind. A nail can hang a picture. If a picture can be hanged on the wall, what else can? Larger wooden shelves can be hanged on the wall if we improve the nail by adding a fastener. Now it's more of a 'mount' than a 'hang.' And so on and so forth.
The overarching question be: "what else could the nail hang, if the nail could hang pictures?" "could it hang everything?"
I think engineers like complexity. We like the ability to control and shape all of our tools.
In my experience, non-engineers, tend to like simplicity.
I have learned that there's a lot more non-engineers, than engineers. Many of them, have a lot of money, that they are willing to spend on things that are simple.
Working with graphic and interaction designers has taught me to suppress my resistance to making things simpler.
No, that's not my experience or understanding at all. Complexity is a byproduct of building something without understanding how all the parts fit together and without having a clear vision for how it will be used. The pyramids were built as monolithic monuments to the glory of a ruler intended to last millennia. They had a clear vision for what the end product should be, how it was going to be monetized and where material and labor was going to sourced before they laid the foundation.
Engineers thrown piecemeal at the edges of a problem will generate complexity. Engineers thrown into a room with a vision for what needs to be built and time to work out an elegant solution will get you to the moon with a pocket calculator.
Eh. That goes for everything.
If an engineer designs something, it tends to be complex, regardless of whether or not the designer has “the big picture,” because they design the whole thing to fit their worldview. Engineers have a complex worldview.
If a UI designer designs it, the chances of it being simple (from a user PoV), is much greater.
Designing a simple UI, in my experience, is often “un-simple,” however. I remember writing a visual cropping algorithm, for a film scanner.
It was a pretty damn hairy library (it ended up being an entire subsystem).
Worked well, though, once I refined and debugged it.
The UI designer might be capable of designing a simple UI but probably has no idea how to design a simple infrastructure, dataflow, logistics, corporate operations infrastructure, finance structure...
You're thinking like a UI designer that's watched engineers without UI design experience try to design a UI. You're referencing a lack of expertise and experience, not some inherent trait in engineering.
People are like a gas, they expand to fill the space they're in. If you have simplicity, you can always just do "one more thing" until eventually you've blown past your ability to understand / maintain / control what you've built. People can't help it, and I believe it maps directly to overeating, homes filled with junk that no one needs, debt, and many other excesses.
To be a good engineer you had to be stubborn in the early days of your career, you had to have tenacity and persistence to understand and solve the problems you saw. Unfortunately that filter selects for people who are prone to going too far into the detail, who get a satisfaction from conquering complexity rather than avoiding it. Given the lack of big picture thinking, they readily fall into herd-like behavior. Given the ego payoff for the complexity, it is very difficult for them to accept criticisms about their process or lack of perception.
"Simplicity is the most difficult of all concepts" -Brian Herbert
"I would have written you a shorter letter but I did not have time"
Simple things quite often require the mastery of understanding a domain. Complex stuff is easy to write.
It plays the same role as feelings to common folk. In other words, most people out there live for feelings: they seek good tastes, smells, comfort and so on. That's their purpose in life. More sophisticated folks collect art or watch opera for the same reason. Brain-heavy individuals enjoy well arranged complexity instead, it provides the sense of mental comfort. All of this stems from our ability to perceive harmony, although in all these examples our ability is glued to lowly things of this world.
[dead]
The better analogy to pyramids was made by Alan Kay. In lack of an arch we get things done with brute force and thousands of slaves. Sprinkling JavaScript will not help with this issue.
If there was one reason people gravitate towards complexity this author is talking about, it's probably because they want to see if they can do it. In some contexts it's annoying, but it's also what moves the needle from time to time.
Unsure. Personally I like simplicity and avoid complexity. Sometimes it can be avoided. However two adages come to mind, "life is complex", and "complexity must live somewhere". Simplification only works so much and is inherently eliminating something that someone or some situation requires. This of course an over-simplification. ; )
We reward people that deal in complexity.
I'm not a very clever person, and I keep things pretty simple, so when I explain something to someone, they can generally get a grip on it pretty quickly.
To them it's been such a small jump they think, that person doesn't deserve much of a reward, heck I could have done it.
Whereas when someone talks about the complexity, people think, wow, there's no way that I could have done that, let's pay that person LOTS to keep them
Flags became simpler and simpler, until they were just two colored stripes with no elaborate drawings etc. Simple is better as long as its enough, its both easier to spot and easier to make, but it is hard to realize when a simple thing is enough so typically people make complex things to be sure it works.
Technological complexity is often like a warm blanket you can wrap yourself in to avoid the realities of the customer.
Many businesses are built in such a way that you have little hope of directly contacting your customer, but that doesn't mean you can't try. The desire for complexity often disappears like magic when a developer gets to experience a client expressing happiness over the end results of their "clunky" tech stack.
Just have a text config file that comes in a variety of preconfigured flavors ("x mode", "y mode"...) and then also offer a "make your own config" option too.
Most of the time, if I'm working in blender for example, I want some really sane prepopulated shader values and one size fits all rig values for sofas vs chairs, but sometimes I want to go crazy and make chairs out of glass and slime, etc.
One reason is the architecture astonauts:
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
It's very simple: Job security.
To convice their managers that only they understand the horrific code they wrote the software in.
When you're 6 procedure calls deep in a model you started from some abstraction on the problem which has hit "well ACKchewally.." variances from the model, it's high cost to go back to top and invent the top level abstraction again, to be only 5 levels deep when you hit the next one.
Putting a late stage "yea I know, but this one time..." hack in, is logistically simpler.
TL;DR we're not addicted to complexity, we're addicted to the abstraction we started with, even when it turns out not to be as good as we thought.
This rings almost true for me - but “addiction” makes it seem like some sort of personal failing, whereas I think the cost of that backtracking and the probability of finding another Balrog in the woodpile later makes it seem like a perfectly reasonable choice.
Source: been there, done that.
Yea, addiction is the wrong word, its hyperbole.
It is perfectly reasonable under the constraint of J Pierpoint Morgan's dictum:
"I don't want it perfect, I want it by Thursday"
Not sure in what context I need to answer this question, but thought is its the complexity created artificially when work culture, work politics, people and their thoughts collide together and resulting in a multi dimentional complex environment
Sure.
For any topic, you might find a perspective that makes it simple.
But then: For a given topic, a lot of parties each bring their own set of simple requirements.
The patterns emerging as the interferences of these requirements might not be simple.
I think for some complexity is a look at me and how smart I am type thing the author talks about.
But simplicity also requieres a lot of effort. Complexity is a side effect of laziness and not putting effort in. Common in corporate programming.
It's because if you're building a skyscraper and you decide - oh heck, who needs architects and steel - that's too complex. Let's build this simple and use plastic.
> In the software world, how would you sell a competitor to the cat command?
It's called bat, and it's a great enhancement. I think the author lost me here.
If you don't over-engineer how will you ever have job security?
In a single word: conscientiousness.
Simplicity requires a deliberate planning consideration plus additional effort to maintain, often through refactoring once new requirements surface to implementation. For some people these additional steps are essential to main clear output and a single deliberate path forward. For other people these additional efforts are an impossible chore best offloaded to some third party.
These thoughts about simplicity apply not just to code but to every decision in everyday life.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." - Edsger Wybe Dijkstra.
Simple/complex is subjective. Software domain is very diverse that it's unlikely we'd agree on them.
Take mathematicians, for instance. They generally have a shared sense of elegance/beauty. That's the result of a refined intuition from years of study.
Not sure why your comment was not received well by everyone here, however, that Dijkstra quote is definitely pertinent.
I believe that anyone can make something complicated and only the few can make something simple. This statement can be read the one way, I don't mean that anyone can make a lunar lander or an atom bomb, what I mean is that over-complicating something is something anyone can do.
At university I discovered another aspect of making things simple. We had one assignment to design a multi-storey car park. The purpose was to demonstrate the use of diagramming, and I handed in a single A3 sheet of paper, whilst all of my coursemates handed in sixty page bound documents. I felt that I was taking a bit of a risk but I was happy with elegant simplicity.
When we got our assignments back, everyone else had a mark and lots of red lettering. I just had a singular tick. I bravely plucked up courage to ask what the tick meant. Our lecturer told me that I had a perfect mark and that I was the only one to understand the assignment.
Since I was not confident in what I was doing, it required a lot of strength to resist the groupthink of the course. I could have folded to crib someone else's solution to turn in my own sixty page monstrosity.
Getting back to web development, I have frequently found myself working with colleagues that go for complexity because 'anyone can make something complicated' and because they lack the confidence to escape the groupthink that goes with doing so.
They seek validation for accomplishing tasks in devious and circuitous ways, and to feel in control of something since they never had that anywhere else.
A lot of it is smaller companies trying to ape bigger ones.
Your 1-10 person team probably does not to use the same tech facebook or google are using, most of the time.
How are those HTML/CSS libraries that don't need Javascript, like Pure, working out?
What if manifesting complexity is the purpose of the universe?
Because for other than trivial problems or systems, requirements are inevitably complex?
I think people don't realize how complex simplicity actually is. FFS, we've all see Conway's Game of Life, right? We all solve hard complex problems by solving simple ones, right? Yet, we have a hard time recognizing that simplicity is complex.
The truth is that simplicity is difficult to implement and even more difficult to maintain. It's easy to oversimplify, as all you need is to not be aware of some complexity. Given that there's infinite depth to things, it's always going to be easier to be missing information than to have enough. But then simplicity is difficult to maintain. Because each time we touch something the same process happens, causing things to compound. If you're 99% "good enough" (a pretty high and unlikely number) then 10 times and you're at 90%[0]. Often a small mistake can lead to big problems. If things run without much slack, then things break. Entropy is a bitch.
The way I think about it is the inverse of how we problem solve. We solve big problems by breaking them down into small problems. Their composition solves the big problem. Consequently, any big problem is composed of many small problems. So I don't understand why we are so dismissive of the little things. The difficulty is figuring out which little problems meaningfully contribute to big problems and which little problems have little impact or are contributing to a different big problem. So when we use dumb thought terminating cliches like "don't let perfection be the enemy of good" we're ignoring the reality of the issue here. If someone believes perfection exists, yes, fix that. But only really junior people think that. Far more often it is a disagreement about what is "good enough" and so the cliche just prevents having a conversation to figure out what that is. No one is omniscient, so why not hash this out?
I think we gravitate to complexity because simplicity is not simple.
[0] This is oversimplified. I'm intending this for communication rather than specifics. Obviously how things compound matters. The numbers are made up but the math isn't. You'll have to read between the lines to determine the complexity that exists for a given situation. I can't be 100% accurate, so let's work together to communicate as best as we can.
Exactly what I needed! You just saved me several hours. Thanks!
[dead]
Because it is easier to keep adding stuff than to remove it.
Original HN title: Why do software developers love complexity
because complexity is the path of least resistance - just add stuff, don't simplify, don't cut...
Maybe when you're a junior, you like watching "the lights flash and the wheels spin" as Steve Summit used to say, but as you get older, more complexity is more stuff you have to audit, maintain, keep in your head as you extend the system, etc. And that's stuff you have less time and patience for. So you are drawn to solutions that are as simple as you can get away with. Especially since systems that did quite a lot with vastly fewer resources are still within your living memory. If you grew up with an Amiga, and your younger colleagues all started with like Windows XP or something, you remember being productive in an environment that they can't even fathom using.
I know this sounds all very "old man yells at cloud". What can I say. Grug dev only telling fireside stories learned from bitter experience chasing shiny rock.
Complex is easier than simple.
> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).
A few things to note here:
1. Given anything more complex than showing a blog post... eventually the complexity of your homebrew vanilla JS will grow until you re-invent React, but unlike React, your implementation hasn't had millions of users ironing out the kinks over well over a decade.
2. using an industry-standard framework makes developers fungible, and that is why companies push so hard for it. You need to develop something because marketing wants it, at best finished yesterday? Hire a freelancer, as long as you keep your code reasonable they won't have much onboarding time, and your own staff can pick up from there.
And that's not just valid for React, it's valid for a bunch more things. Wordpress comes to my mind first and foremost - yes it's PHP of questionable quality and with loads of legacy garbage, but even in the most remote outback village you'll be able to find some college kid doing wordpress stuff for local businesses as a side hustle. Symfony and Laravel for more complex applications. And for anything Java, there's a reason Spring + Tomcat have grown to where they are, it's just the same.
Answer: simplicity may not scale.
It's just a misfire on foresight. People writing code try to make the computer do most of the work. When they miscalculate the axes along which the machine must evolve it looks like unnecessary complexity. The structure of human interaction dictates the rest: no engineer fitting a piece into a port built for it in software thinks the designer of the software a genius - he thinks himself the genius for having fit it to the port; but every engineer who doesn't find the port thinks the designer an imbecile.
I take issue with the first sentence (but not the idea behind). The problem IS that developers don't build pyramids. They build fanciful architectures and expect them to support pyramids. Complex can never be the bedrock for simple.
Because complexity isn’t formally defined. We don’t have any formal definitions of what it is and as a result we don’t even have any algorithms that can reduce complexity.
Thus because there is no theory, much of software is like art. Just a bunch of arbitrary techniques. That is what OOP is. OOP techniques have no basis in theory or formality yet it masquerades as something formal with big overly complex nomenclature like dependency injection and inversion of control as if any of these techniques mean anything formal.
I digress. Anyway because we don’t have a formal definition of what complexity is we often dont know what direction we are moving in. Is it more complex or less complex? Who knows?
So until someone comes up with a formal definition of what it is we will just be moving in circles.
Complexity is the thing that keeps a certain, very common type of engineer excited. If left to their own devices they will increase the complexity of the solution in such ways that it can just be comfortably managed by themselves (if they have a good run) or just a bit too much so they are struggling all the way (if they have a bad run). The complexity of the problem is more or less irrelevant then.
There are many software products which solve extremely simple problems in very complex ways, sometimes this is called "overengineered". It is what happens, when the simple solution was too boring or when there was a shiny technological hammer and suddenly every problem looked like a nail (think of blockchain products where a simple relational database would have done the trick). This problem exists in hardware as well, but to a much lesser degree, because in hardware every tiny bit you add is cost added to the bill of materials, so hardware engineers have more incentives to keep simple solutions in mind.
To some engineers, them being the only person thar understands the code is a feature, not a bug. That either means they tricked themselves by making the problem appear harder to solve than would be the case (for the own ego), or they tricked others into a co-dependency where the engineer is now needed to understand the solution (for job safety).
One has to admit tho, that some problems are just inherently complex themselves and you have to tackle them at their own level. For example identity managment systems with people from potentially multiple sources where the data shape and quality is out of your control and you still need to reliably create one identity from the data sources. This is a classical: "How hard could it be?"-problem (turns out: very). The solution to that will be complex, because the problems you encounter are. The solution will need to be adaptable because new problems and needs will arise. The solution needs to be maintainable for the same reason. Complex problems + complex requirements = increased complexity in the solution
True mastery in software engineering means the complexity of the solution meets the complexity of the problem, while delivering in all kind of other dimensions like maintainability, legibility, adaptability, security, safety, reliability, ruggedness in changing OS-environments, ease of use, etc.
Many software engineers you will encounter are still in their "write and forget"-stage of their career. They never had to face The Sysamdin that had to deal with their flaming piece of crap software falling apart with every second system update. They have next to no admin experience themselves, that would tell them that good software chugs along for decades in a changing environment.
The problem with complexity in software engineering is that we can just add it. No beancounter breaths down our neck if we add an extra dependency. The problems arising from added complexity are intangible until they aren't, and then it is often too late.
P.S.: I smell chatGPT in some of the phrasing like: "Complexity shouts, “Look at me!”, while simplicity whispers “Did you notice?”."
because simplicity is hard
This is a "wild" hypothesis. A scifi WIP.
The desires of certain character types culminate in leadership. Those with this character type who have actual visions that fit withing the symbiotic nature of our reality were about as wanted among their peers as alphas were wanted in human tribes where betas felt treated unfairly and thus ganged up on alphas and their offspring, then establishing fraudulent hierarchies alienated from individual competence, which was compensated by collectively established complexity that served to maintain and uphold the fraudulent hierarchies.
Over time, in IT, engineering and science, this lead to narrower and narrower fields of possibilities, aka probabilities that certain behavioral locks and refused directions and angles will be unlocked (after emerging).
Business psychology, marketing, sales, and culture and psychology are entangled and "envelop" instead of developing. It appears like an evolution but it's an alienation, a contiguous/continuous self-imposed, self-reinforcing isolation from and within a symbiotic, open system.
The complexity forces the reduction of productive points of friction in order to create atomic points of contact with the parent system that minimize even productive and constructive influence. This then enforces rules of self-preservation instead and dictates dogmas of engagement with the rest of the world.
It's the obfuscation of the oldest Ponzi scheme which prefers isolation in singularity rather than a symbiotic evolution. The first who makes it to the patent office vs FOSS. Factory farming for a fancier dinner table. Who cares how much is thrown away, how much energy is wasted and how any of that impacts the chemical cycles of a symbiotic system that kept optimizing for exactly that for billions of years--by design, via self-organization, not necessarily as a hard-coded yield. The world wide web feels similar, btw.
Again, it's a WIP. (I just whipped those paragraphs up, but there's an imaginary pin board with a lot of sticky notes ...)
[dead]
Two words…
Job. Security.
You see, if only you knows how it works, how could they get rid of you? /s (obviously /s)
[dead]