Genuine question, is it a property of software design only? Think about construction, for any change in the architecture, one has to demolish stuff and make a mess.
I'd argue, that's a general property of change.
Software design gets worse before it gets better
101–110 of 145 posts
Re: Software design gets worse before it gets better
#102Absolutely. There's a gap between code which expresses/communicates its intentions and code which achieves the same goals while being much more streamlined and suited to the constructs of the language.
Re: Software design gets worse before it gets better
#103To boil it down simple: People are vaguely good and competent, they leave systems in a locally-optimal state. In general only changes that are "one step" are considered, and they allways leave things worse when you are currently in a locally optimal state. A multi-step solution will require a stop in a lower-energy state on the way to a better one. Monotonic-only improvement is the path to getting trapped. Take chanc…
I think "better" is ambiguous. Better for developers? Better for users? Better for speed? Better for maintenance? Better license? Better software stack? Better telemetry? Better revenues through subscriptions?
I would disagree with that. We have quality measures to assess what 'better' can mean in software engineering (e.g. maintainability, reliability, security, performance, etc.).
You are right that it is not fixed what is most important. It may vary from one organization to another, but it can be conceptualized and then made measurable to some degree.
Re: Software design gets worse before it gets better
#104Earlier quoted context omitted.
I think "better" is ambiguous. Better for developers? Better for users? Better for speed? Better for maintenance? Better license? Better software stack? Better telemetry? Better revenues through subscriptions?
At a business, all of these - a good engineer/architect has to find the right balance.
Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.
Re: Software design gets worse before it gets better
#105Earlier quoted context omitted.
I didn't say that evolution finds the optimal state, just wanted to highlight how far it was able to go, much farther it seems.. (like evolution of the eye) But your comment was refreshing, could you briefly expand on the "multicellular" life part? Did you mean that it enabled more non-locally-optimal transitions, or that it required them to appear?
I think cooperation is never a locally optimal strategy. Somebody allways gets to pick second at the prisoner's dilemma table, and locally optimal behavior is to eat the trusting idiot. Takes a lot of luck to evolve cooperation multiple times at once, much more likely to happen in a situation where the selection pressure is lower, not higher.
Pretty sure those non-cooperative strategies quickly burn themselves to extinction though. The selection pressure itself would be regulated towards an equilibrium.
The thing about evolution is that you are sampling many times in different directions. So "luck" isn't that hard to achieve.
Re: Software design gets worse before it gets better
#106Earlier quoted context omitted.
Because Wayland is worse than X11. Unfortunately, it is true that sometimes after your software design gets worse it gets better, but other times after it gets worse it gets worse. It's not correct to assume that something will get better just because it is currently worse.
Wayland went for minmalism because one can always add things later. Unfortunately, making additions in a multi-desktop environment turned out to be kinda difficult. In a way, the quality of the design (and implementation) is fine, but the quantity of features is insufficient and limited by social issues. It's basically the opposite problem of systemd.
Wayland is not trying to do enough. You can send pixels to a compositor - great. It turns out a desktop is more than just pixels sent to a compositor. It turns out X11 has a lot of stuff because there is a lot of stuff to do. It could be simplified somewhat, producing incompatible X12, but not simply thrown away along with all the accumulated knowledge. It's literally the Joel Spolsky "never rewrite Netscape" effect in action. Wayland has now spent nearly a decade reaccumulating a part of the same knowledge that was already known, but worse.
Re: Software design gets worse before it gets better
#107Earlier quoted context omitted.
Because Wayland is worse than X11. Unfortunately, it is true that sometimes after your software design gets worse it gets better, but other times after it gets worse it gets worse. It's not correct to assume that something will get better just because it is currently worse.
It seems the other way around: x11 got worse and worse, then wayland happened (wayland core).
In what way did X11 get worse and worse? It's one of the most stable protocols in use - outliving HTTP, IIRC. It didn't change - our expectations did. Sure, there are incremental improvements to be made, and incremental improvements that have been made, all of which are optional and therefore couldn't have made it worse.
Re: Software design gets worse before it gets better
#108Earlier quoted context omitted.
Evolution regularly ends up in local optima that it struggles to get out from. Species go extinct all the time when there's no evolutionary path that solves its problems.
And on the flip side, a sufficient abundance of resources and/or lack of predators mean non-optimal species can procreate, and thus find other local optima.
In terms of evolution, the fitness of a species is defined by its ability to reproduce. In the circumstances you describe, selection pressure exists for the species that can reproduce the fastest. Predators or resource constraints are not a requirement for evolution.
Re: Software design gets worse before it gets better
#109Earlier quoted context omitted.
At a business, all of these - a good engineer/architect has to find the right balance.
Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.
It's not ambiguous, it's a collective decision between engineers and business stakeholders. The ambiguousness comes from engineers not having full information.
Re: Software design gets worse before it gets better
#110Earlier quoted context omitted.
At a business, all of these - a good engineer/architect has to find the right balance.
Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.
I think this is actually addressed in the article:
> The key question for the designer is, “What would the system’s structure need to be so that would be no harder to implement than necessary?” (It’s a bit surprising when designers don’t ask this question, instead simply asking, “What should the design look like?”—for what purpose?)
During my career, I have been in many situations where the SW architects tried to answer the second question: as if the architectural cleanliness was the goal unto itself. Software design patterns were misused, unneeded abstractions abounded everywhere, class hierarchies were created 15+ levels deep. There it was often brought up which is better and nicer and cleaner because the metric was aestetics.
Most of those arguments, however, are quickly brought to a stop, if we are actually asking the first question: how hard is it to add these new features? That said, I was frequently unable to convince coworkers in my past employments, that aestetics of the design is not the goal. They simply clung to it, to somewhat religious extent, identifying themselves with their "artwork".