I'll start with two questions:
Is complexity inevitable in software development?
How much of this complexity is our failure to curb "accidental c...
For further actions, you may consider blocking this person and/or reporting abuse
Accidental complexity feels inevitable because we don't have perfect knowledge/understanding of the problems we are solving. We can really only get close to having that after we are done with a project, when it is too late. Just like life... you only know what you should done at the end.
But some approaches seem to grow accidental complexity at a faster rate than others.
Any examples?
Far and away the biggest is focusing on the tools instead of the customer's problem. Accidental complexity ramps up quickly. Been there. I still remember coding and thinking things like... "I don't understand why they want this." or "This requirement is going to be awkward." And instead of asking about it, I filled in my own assumptions. And it didn't turn out well.
Tl;Dr isn't this more about the imperfect 'celebrity' tools you know to exist than the tools that are perfect that you've never heard of?
I don't have any good answers, but I do have a point that adds complexity to your initial query. A 'meta-complexity' if you will.
Do projects like rust and react have extra 'mind share' because of the success of Mozilla and Facebook, and so it's harder to be unaware of them. As a result, we echo chamber the existence of the tools more effectively, and so increase the odds of any one project choosing these technologies for a problem Vs a more home brew, but arguably more suitable technology that exists but has significantly lower awareness around it, as the developers are working on it in their spare time, or its backed by a really small company no one has heard of?
Sure, it's also definitely a problem of reach. But that's true for everything. I cannot care about the perfect tool that's out there if I don't know that it exists. It's a tautology. I do not have opinions on things I don't know I should have opinions about :D
Staying the realm of the known, in my final question, the "a thousand different reasons" I include many of the logical choices (as in "of logic") we make factoring in: time to market, the ability to sell something to colleagues or managers, familiarity, marketing, time itself (as we can't take forever to make a choice), the perceived malleability of software ("well, if it's the wrong tool, I'll change it down the line"), "wisdom of crowd factor" and many others.
I too don't have an aswer. I wonder if it's because there simply isn't one.
I think you're probably right, all the way through :)
PRESENTATION "7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development" by Joe Rainsberger, from the Agile Lightning Talks (2013). Which I link here because he talks about accidental complication and how to minimize it. He intentionally uses the term complication rather than complexity, but even so it is within relevance for this discussion. And I really like Joe's talks, and I think his messages are on point. And he says quite a bit in a mere 7 minutes and 26 seconds!
One aspect that was not mentioned yet: I would argue that developers tend to worship complexity (as explained by Eberhard Wolff). Either it's because we as developers simply don't know better but to use the tools we've already worked with (which seems like accidental complexity to me) or because we are arrogant (from the linked blog post: "Our challenges are much greater than those of Amazon or Google.")
Adding this thought from a proper rant: I want off Mr. Golang's Wild Ride:
Here we have a language, like Go, who's marketed as simple and beginner friendly (which it is, it's not a lie) and by its design and its choices inevitably has to hide some complexity. What happens, according to the author and other people he links to, is that some of these choices are made at the expense of correctness.
Is simplicity even achievable if we decide that complexity is inevitable? I think this is why language design is so hard. Software itself is an attempt of managing complexity while trying to solve a problem.
If we say that Go's designer did a terrific work at hiding complexity (and they did, I'm not disputing that), is Go's blanket too short or at least not big enough for stuff to crash and burn when you start exploring those borders?
If you're familiar with Go, the entire discussion around error handling and interface management vs generics is a discussion around simplicity of usage vs complexity of domain.
It takes a few lines of code in Go to make a concurrent program, but it takes roughly the same amount of code to make an incorrect concurrent program.
Where does the real issue lie here?
Every Railsconf keynote DHH gives is generally a rant against software like React. Regardless of individual preferences for certain APIs, I think projects are going to be built to favor the highest needs of its main decision makers.
If I think about the needs of big Rails decision makers, folks like Shopify have certain obvious needs to make the software work for them, and then DHH's camp's needs seem more in the realm of need to be righteous about certain software development topics. This generally seems like a good thing, but it's also just the way things are. If it ever weren't a good thing it would be hard to distinguish.
To speak to the work at Forem, our software has a certain complexity associated with its needs to power a public, global community like DEV— But I'm excited about the forcing factors of smaller communities. DEV needs to be a "powerful" engine in a lot of ways to deal with the complexity of human scale, but smaller communities need more simplicity than power in many ways, especially closed communities which mostly trust all the users implicitly.
If we resigned Forem to only being designed for communities at the scale of DEV or bigger, it might allow us to accept extra complexity or bloat.
True, one of the other aspects in the usefulness of tools is the ability to scale down. But that's probably the center of my argument and it's probaby tangential to the concept of "silver bullet". If a tool that's able to scale up, down, left and right is essentially a silver bullet, so if silver bullets in software are a chimera, aren't we the ones that are bad at labeling those tools?
I quote myself here:
I should have added: "If so, does it matter, if the choice is good enough?"