Why do we keep gravitating toward complexity?
kyrylo.org
kyrylo.org
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.
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.
"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.
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.
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.
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.
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.
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").
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.
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.
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?
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?
And yet fails to provide a single example.
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.
No, they do it because it's simpler.
Using react for simple simple things makes it not simple.
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?
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.
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.
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)
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.
But normally I'll use the drill even though it's overkill, because I got other stuff to do :P
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.
[1] "Simple Made Easy" - Rich Hickey (2011) https://news.ycombinator.com/item?id=23905051
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.
> something that looks 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.
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.
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 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.
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.
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.
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.
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.
some side effects may occur
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.
They 100% had these.
https://en.wikipedia.org/wiki/ScanPyramids#ScanPyramids_Big_...
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.
This was the Pliny view.
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.
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.
> 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.
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
> 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.
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.
Ascii delimiters will not save you there.
At any rate, great read.
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.
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.
'We'll fix this later, now just make it work'
It takes more effort to make things simple than to make them complex.
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.
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.
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?
> 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.
Complexity adds tension.
Bored Software developers add complexity to make their jobs more interesting is my take.
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".
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!
> 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.
> 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.
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.
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.
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
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.
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.
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.
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
> 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?
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 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.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Or if you wan to have more fun read Systemantics
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.
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
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).
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.
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.
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.
-- C. A. R. Hoare"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?"
Simple things quite often require the mastery of understanding a domain. Complex stuff is easy to write.
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
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.
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.
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.
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.
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.
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.
An example being the increased inefficiency, and rate of fuel consumption of aircraft with quadratic air resistance.
To convice their managers that only they understand the horrific code they wrote the software in.
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.
Source: been there, done that.
It is perfectly reasonable under the constraint of J Pierpoint Morgan's dictum:
"I don't want it perfect, I want it by Thursday"
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
But simplicity also requieres a lot of effort. Complexity is a side effect of laziness and not putting effort in. Common in corporate programming.
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 ...)
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.
It's called bat, and it's a great enhancement. I think the author lost me here.
Your 1-10 person team probably does not to use the same tech facebook or google are using, most of the time.
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.
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.
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.
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.
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.
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?”."
Job. Security.
You see, if only you knows how it works, how could they get rid of you? /s (obviously /s)