Tips for avoiding second system syndrome [closed]

Question

Lately I have seen our development team getting dangerously close to the 'second system syndrome' type ideas while we are planning the next version of our product. While I'm all for making improvements and undoing some of the mistakes of our past, I would hate to see us stuck in an endless loop of rewriting and never launching anything.

Is there a good design / development method that lends itself to building a better version 2.0 while avoiding second system scenarios?

Answer 1

I have experience the second system syndrome from both sides as a customer/sponsor and part of a development team.

A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software "flexible". In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic "item" object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as "flexibility" overshadows the effort to a point that the resulting software doesn't work.

A balanced practical consideration of usability, performance, scalability, features, maintainability, and flexibility goals can bring the team back to earth. "It would be great if..." should be prohibited from the vocabulary of the team. The Scrum backlog is a good tool and the team should be heard saying often... "Let's backlog that...we don't need that for version 2."

Answer 2

"I would hate to see us stuck in an endless loop of rewriting and never launching anything."

Which is why people use Scrum.

1. Define a backlog of things to build.

2. Prioritize, so that things which lead to a release are first. Things which should be fixed are second.

3. Execute sprints to get to the release. Execute a release sprint.

Answer 3

Get someone who has written at least three systems to lead the project.