16

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?

spender
  • 117,338
  • 33
  • 229
  • 351
Wally Lawless
  • 7,539
  • 7
  • 37
  • 53

9 Answers9

17

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."

Jim Goodell
  • 171
  • 1
  • 2
11

"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.

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • Thanks for the answer, I chose it as correct because it is concise but gets the workflow across well. – Wally Lawless Jun 16 '10 at 13:34
  • 7
    Scrum doesn't keep you from creating a "second system". It just manages your workflow. "Second system syndrome" is majorly an architectural issue. (besides, I don't like Scrum). – Rolf Jan 15 '14 at 13:49
4

Try to focus on short delivery cycles, i.e. force yourself to deliver something tangible and useful to the users every few weeks or month. Prioritise the tasks based on their value to the customer. This way you always have a usable, functional application with satisfied users, while under the hood you can refactor the architecture in small steps if you wish (and if you can justify the need for it - that is, towards management / the customers, not just teammates!).

It helps a lot if you have a stable build process with a good suite of automatic (unit / integration) tests.

Agile development methods like Scrum do this, and they are warmly recommended. But of course it is not always easy or even possible to adapt such a method in your team. Even if you can't, you can still take elements of it and apply it to your project's benefit (maybe without even mentioning the words "agile" or "Scrum" publicly ;-)

Péter Török
  • 114,404
  • 31
  • 268
  • 329
4

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

Nat
  • 9,820
  • 3
  • 31
  • 33
  • 2
    +1 Hiring someone who has successfully built a similar solution is up there in my top 10 best project management practices. –  Feb 17 '10 at 15:21
  • Except ideally, you want someone who has written three iterations of the same system. Someone who has written three "second systems", or even three "first systems", may not be what you want. – Warren Dew May 04 '16 at 03:40
3

Make sure you document the requirements as well as possible. While obviously you need to also manage what gets into the requirements to avoid over-designing, having a fixed scope helps prevent developers from running off with ideas or gold-plating what needs to be done and it helps keep management or clients from introducing scope creep. Define all requirements and how scope changes will be addressed.

I'm all for short development cycles (make sure you're writing tests) and agile methodology, but neither of those is a shield against second syndrome system. In some ways it's easier to keep adding on feature after feature if you're working in short sprints without stopping to look at the overall picture. Use agile practices to build the simplest thing that works, then keep adding your other requirements as simply as possible. Remember YAGNI, because when you build a system a second time, that's when you're most likely to build something you're sure you'll need at some point, something that will make the system "extensible" so there never has to be a third build. It's the best of intentions, but the road to hell and all that.

Tom
  • 22,301
  • 5
  • 63
  • 96
  • Upvoting because surprised that more answers don't mention YAGNI. In my opinion, the key to limiting scope for a rewrite is to find a balance between excluding features and/or support for features that aren't immediately required in order to fulfill the hard requirements on the one hand, and not 'painting yourself into a corner' as regards the possibility of adding that feature support at a later date on the other. ie. the optimal rewrite is a lean core implementation, but with the most minimal 'refactor distance' to the 'possibles' that you can achieve without adding redundant complexity. – jlmt Jan 24 '16 at 17:09
2

You can't get close to second system syndrome. Either you're in it, or you're away from it. You'll know when you're in it, but only after wasting a lot of resources.

Tips are: know about it (so basically we got that covered already). It's invaluable information to know what a "second system" is, and even more to have some experience with that. I think we all have some experience with that, hopefully benign.

That knowledge will often make you think twice and you'll find a solution without venturing into second-system limbo.

PS: Also know how to use your current system, that includes, maybe documented solutions, and other documentation.

Rolf
  • 5,550
  • 5
  • 41
  • 61
1

Focusing on the system architecture should help e.g.

  • Having documented interfaces which support "loose coupling" between sub-systems
  • Having documented design decisions (avoid re-hashing previously beaten paths)

Hence, without going for an all out swap, the current system can be "upgraded" with more appropriate interfaces to help future growth.

Another good way to focus: assign a $$$ figure to each feature and prioritize accordingly ;-)

Anyhow, just my 2cents

jldupont
  • 93,734
  • 56
  • 203
  • 318
  • Isn't that the problem - it's easy to focus too much on re-architecting the system, rather than getting the enhancements/bug fixes for 2.0 done? – Dominic Rodger Feb 17 '10 at 14:58
  • +1 for the "documented solutions" (ok, actually you said documented design decisions...). A "second system" can be brought by just not knowing how to do things with the actual system. – Rolf Jan 15 '14 at 13:50
1

I up-voted S. Lott's answer and would like to add some more suggestions:

  1. Deliver a working product to your customer as frequently as possible. Iterations lasting between a few weeks and 2 months are ideal. Agile methodologies, such as Scrum, lend themselves well to this.

  2. Use FogBugz for feature and bug tracking. Its features are very practical for agile projects. FogBugz allows easy prioritization according to releases and priorities. If your team enters their estimated levels of effort for each task, you can also use this to calculate reasonable ship dates.

  3. Prioritize which features you will develop according to the 80/20 rule (20 percent of the features will be used 80 percent of the time) and the most bang for the buck. This helps keep the system as simple as possible, helps prevent feature bloat, and saves development and testing time.

  4. Give similar thought to both new features and bugs when you determine the priority of an issue. One point of the Joel Test is "Do you fix bugs before writing new code?". In most shops this doesn't happen, but do not make debugging the system an afterthought. Also, keep a working copy of the old system to compare against when bugs are found on the new system.

  5. Also factor in the level of effort required to maintain, and if necessary rewrite, existing code. If you have not already done this, give the team some time to code review whole files that they find troublesome to change. If the system's code was difficult to maintain the first time, this will only get worse and cause your team to spend more time on new features down the road.

David
  • 1,187
  • 1
  • 10
  • 22
0

It can never be avoided at its entirety. But being cautious could alleviate the problem. You should formulate some thumb rule based on the vital parameters (scarcest resource) that define the success of the system. For example, reducing potential number of bugs might directly decrease operational cost (potential service calls to support center). But this might not be the case in every other systems. Another example, scarce use of CPU, memory and other resources might be beneficial in some cases but there could be environments where they could be available in abundant.

So simply to avoid "temptations", identify the scarcest resource (time, effort, money$ etc) and consider implementing only those that exceed threshold value.[f(s1,s2...) > threshold]

Despite the iterative development, I would emphasize on how technical debts are handled.
Links that are related to this:
Tech Debts: Effort Vs Time
Tech Debt Quadrant

Lokeshwer
  • 1,139
  • 1
  • 9
  • 14