[zhdc1]

This is a naive question from someone who hasn't been involved in project management in almost a decade, but why can't feature development and refactoring be split across two different ownership groups?

The first group writes the initial version and all iterations (extra features) up to the point where the expected returns from quickly pushing out future iterations is less than the amount of required effort.

The second group then comes in and does a complete refactor, without changing the look or feel of anything that the customer actually wants. Meanwhile, the first group moves onto "the next big thing".

[gumby]

There’s a parallel comment warning of the second system syndrome, but I’d like to point out the problem of “who gets the credit?”

Google famously suffers from this: the pm who launches a product gets promoted; the person who adds a feature gets some credit in the employee review and the person who fixes bugs is judged to have wasted their time.

I suspect Apple has this problem too (they definitely prefer reimplementation rather than evolution in many cases) but their processes are more opaque.

Who would want to be on the cleanup team when the glory goes to the path breakers?

[zhdc1]

> Who would want to be on the cleanup team when the glory goes to the path breakers?

This and the second system syndrome are both organizational issues. Why couldn't an organizational simply freeze the customer facing portion of the application (so no UX or added features) and tell a group of developers responsible for the refactoring that they will be judged on a set of achievable metrics, such as decreased infrastructure costs or better performance?

This would fall squarely within common managerial frameworks (it's basically Tuckman's group development model, or what you see at many startups that launch an MVP), except that the initial application development is handled by a different group of 'high performing' developers.

[tyre]

Because there are benefits that aren’t quantifiable. Developer velocity is incredibly challenging to measure objectively.

These initiatives have to be top-down priorities in the organization, with agreed upon importance.

[adrianmsmith]

1) The reason why such a refactor might be necessary is from things the first group tried but didn't quite work as intended, or that the users used the system differently to intended. The first group has that knowledge, the second group doesn't. So the first group will do the refactor better than the second group.

2) Beware of Second System Syndrome https://en.wikipedia.org/wiki/Second-system_effect where everyone tries to put in every feature that was missing from the first system, simply because there is no urgency around the second system, because the first system is already running.

[pixl97]

Battle plans never survive first contact intact and software never survives customer deployment intact. Especially in systems that are ever evolving.

[johnthescott]

so true, in my experience.

[gitgud]

The "rockstars" who write the first system will be despised by the "clean crew" who have to maintain it after its no longer easy to add features...