Software design gets worse before it gets better
tidyfirst.substack.com
Software design gets worse before it gets better
1–10 of 145 posts
Re: Software design gets worse before it gets better
#2Re: Software design gets worse before it gets better
#3https://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.
Re: Software design gets worse before it gets better
#4https://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.
Yes. And Joel Spolsky had a complementary thesis. Written quite well.
Re: Software design gets worse before it gets better
#5The 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 duct-taping libraries, frameworks, and best practices together.
Re: Software design gets worse before it gets better
#6https://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.
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 increments however, usually with just-written code.
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?
Very contextual of course, but sometimes you have to explore a little bit to know the right places to make tradeoffs.
Re: Software design gets worse before it gets better
#7At 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 things quickly, I think that’s good, but that’s also technical debt if the redesign never results in a benefit.
Re: Software design gets worse before it gets better
#8Earlier quoted context omitted.
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.
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.
Re: Software design gets worse before it gets better
#9https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I wonder how this translates to today's microservice craze that is more of a infra/devops/org decision that leaks into the software design in various imo detrimental ways. I can certainly see scenarios where merging microservices could unclog the pipes immensely - but I guess that could be construed as a rewrite.
Re: Software design gets worse before it gets better
#10Earlier quoted context omitted.
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.
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.