I wouldn’t refer to the intermediate states as a software design. The “trough” is the transition from an old design to a new design. But it’s not a software design itself, and therefore not a worse design. It’s just the fact that if you can’t go from the old to the new design in one go (a typical situation), then you’ll have an intermediate phase where the code base is in a more inconsistent and/or complex state, and therefore objectively worse if it were to stay in that interim state. But it’s not the software design that gets worse before it gets better, unless you’re doing some design exploration (hopefully not in production).
Software design gets worse before it gets better
21–30 of 145 posts
Re: Software design gets worse before it gets better
#22Earlier quoted context omitted.
I suppose you could interpret Joel's essay as a bit of an agreement with Kent's take. That even though you might have to pass through a trough of despair to rework some old code into something better - that's still a better path to follow than a ground-up rewrite. I'd usually agree, especially as things get big. But Kent is also pretty famous for throwing out code if things aren't shaping up. He does this in micro in…
> I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off? That's the main reason we have this discussion in the first place IMO. There is no one right answer to the question.
Which is why I find folks that throw out Joel's article to be a little black and white. Like "never rewrite anything from scratch".
It takes many years to develop good intuition around this stuff though, so I appreciate that as a first approximation. It can get a little dogmatic amongst senior folks though.
Re: Software design gets worse before it gets better
#23Earlier quoted context omitted.
I suppose you could interpret Joel's essay as a bit of an agreement with Kent's take. That even though you might have to pass through a trough of despair to rework some old code into something better - that's still a better path to follow than a ground-up rewrite. I'd usually agree, especially as things get big. But Kent is also pretty famous for throwing out code if things aren't shaping up. He does this in micro in…
I've made a career out of bashing half-baked code into shape, or dragging legacy code to meet new needs. You have tests? You can be much more confident about where you're going. Usually the first thing I do when dealing with code is write some tests to capture how it behaves now, before making any changes.
That sounds familiar :) Keep in mind the existing tests are typically half-baked too, so there's lots of additional testing going on no matter what.
Sometimes I just reflect on YEARS mucking with code written from someone that was just learning, and I wonder if I'm a little too in the "sunk cost investment" mindset. Hard to tell I suppose, but certainly worth thinking about.
Re: Software design gets worse before it gets better
#24At first glance I didn’t like this article (due to a long history of poorly executed redesigns for design’s sake) so I gave it a few minutes and reread it, and now I like it. Sometimes when reviewing people’s redesigns, I can’t see the beautiful thing that they’re envisioning, only the trough. And over the years I’ve noticed that a lot of redesigns never make it out of the trough. I like the idea of doing small thing…
You can build stairs on the near side of the trough before you commit to climbing down into it.
Prototyping and figuring out where the most friction is, chipping away at it with each new feature that touches that area.
One of the cleverest things I figured out on my own rather than stealing from others, was to draw the current architecture, the ideal one, and the compromise based on the limits of the our resources and consequences of earlier decisions. This is what we would implement if we had a magic wand. This is what we can implement right now.
It’s easier to figure out how to write the next steps without climbing into a local optimum if you know where the top of the mountain is. Nothing sucks like trying to fix old problems and painting yourself into new corners. If the original plan is flawed it’s better to fix it by moving closer to the ideal design than running in the opposite direction.
What usually happens is people present an ideal design, get dickered down by curmudgeons or reality, and start chopping up their proposal to fit the possible. Then the original plan exists only in their heads and nobody else can help along the way, or later on.
Re: Software design gets worse before it gets better
#25The multi-dimensional nature of this problem makes it extremely fascinating to me, even twenty years into my career. There's a certain dopamine hit you get for voluntarily trudging into the trough of despair, pushing the Sisphyean boulder of better design uphill in the optimistic belief that you can do better, and then actually arriving at something slightly better. Way more fun than conceptualizing programming as du…
Only if people wouldn’t switch jobs every 2 years.
Only if new joiners wouldn’t feel like they have to “show up with something” making existing stuff obsolete.
Well not blaming people or companies just thinking out loud.
Re: Software design gets worse before it gets better
#26Needed this today. I think sometimes engineers go crazy and go try to greenfield something, anything, because building stuff requires it being in a nonfunctional state for a sec and this is hard enough on its own but there being (understandable, but often very counterproductive) friction around that that comes from what you're working on being something someone is relying on can make it a really daunting and frustrat…
Needed this post and this comment. And hopefully I'm not misreading either. Halfway through my greenfield redesign that I claim is catharsis because I was too scared of breaking things before they got better. I hope that I can put that redesign to rest and actually make progress with the original code.
Re: Software design gets worse before it gets better
#27I always think of projects as something you constantly iterate on, rewriting in my experience has always been a mistake.
Re: Software design gets worse before it gets better
#28At first glance I didn’t like this article (due to a long history of poorly executed redesigns for design’s sake) so I gave it a few minutes and reread it, and now I like it. Sometimes when reviewing people’s redesigns, I can’t see the beautiful thing that they’re envisioning, only the trough. And over the years I’ve noticed that a lot of redesigns never make it out of the trough. I like the idea of doing small thing…
> Sometimes when reviewing people’s redesigns, I can’t see the beautiful thing that they’re envisioning, only the trough.
Distinguishing between the idea and the implementation is vital.
If the idea is good then a few rounds of review is all that's needed to shore it up. If the idea is bad, then there's more work to be done. Letting people know that you like the idea is key. There's also room for being okay with the implementation if it differs from how you'd do it.
Re: Software design gets worse before it gets better
#29https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Kent Beck is not talking about rewriting from scratch. He's explaining how to transform software to a better state by taking tiny steps in changing the existing system.
It seems no one here quite knows what he is talking about.
Then you read his latest book "Tidy First" and it tells you when you move out multiplying width and height into an area function you have now made a beneficial design change in your system and the relationship between caller and box, a "tiny step". And suddenly all the doubts wash away.
Not sure what it is with this industry, but the writing is just useless.
Re: Software design gets worse before it gets better
#30good design and implementation requires skilled people. you don't get either with bottom of the barrel pay grades. something I have noticed in this industry is that big companies think they can outsource their staffing issues and "save on labor". But in the end they pay more in management of outsourced assets, inevitable maintenance of poorly designed and implemented software, delays in delivery, and of course the ch…
It's beautiful that this sort of expediency often comes back to bite decision makers. Unfortunately, the timescale in which it occurs makes it very possible to simply ignore the fact that they created the problem in the first place.
This also is why I do not believe LLMs pose as big a threat to software development as we're told. Maintenance will always require humans that can simultaneously comprehend the system as it is today and the system as it should be in the future.