I should be careful how I talk about rework. It would be easy for me to make it sound like all rework is bad.
I don't think that's true. At least, I don't think I want it to be true.
Sometimes, rework means the team learned something useful.
You test a form with real people and realise the wording doesn't make sense. You watch someone try to book an appointment and see where the flow asks too much of them. With prototypes, maybe you review it and notice you've made an assumption about how people will understand the next step.
That kind of rework feels healthy to me. I may find annoying sometimes. It's definitely slower than pretending the first version was fine. But at least it's healthy.
Rework sometimes is good. That doesn't bother me at all.
Then there's the more neutral kind. Neither good nor bad. Just part of the regular work.
That's when the entire design and approach changes after constructive critique. Or when the content gets clearer after careful review.
That's part of making software.
But this is not the rework I'm bothered by either.
The kind I'm more interested in is the rework that keeps coming back.
The same damn issue shows up in every new form. QA finds the same problems the team could have caught earlier. The small fixes that turn out to be more of a widespread problem that I thought.
This kind of rework feels different.
But I'm trying not to turn that into a rule too quickly. Maybe the better question is not if rework is bad. Maybe we look at rework and wonder if it taught us anything new, help us make better decisions or change how we work.
I'm still working through this.
But for now, I don't think the goal is to remove all rework.
I think the goal is to notice which rework helps the product get better and which rework tells you the team is paying the same tax again.