Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite

http://en.wikipedia.org/wiki/Second-system_effect

The second-system effect refers to the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors

When starting work on a follow-up project that will share the same codebase as the previous project, how do you control the second system effect? How do you stop yourself going overboard on rewriting flaky systems? How do you restrict "wouldn't it be cool if..." new features?

I find one of the biggest factors is complacency from familiarity with the codebase. It can be very easy to add new features by "hacking" together systems that you know inside and out. However the short-term gains are outweighed by the spaghettification of code a few iterations of this approach can produce. How can you coerce programmers to design and implement features properly, when the "quick hack" solution is so tantilising?

share|improve this question
Wow... I don't know how to respond to this. The question, and all of the Scrum-focused answers are just off, misled, it appears to me by the phrase that will share the same codebase as the previous project -- second system effect doesn't compare X to X 2.0, but to a next-generation system that shares goals, but not code. ( C to C++, Win 3.1 to Win NT, SunOS to Solaris, Mosaic to Netscape, IPv4 to IPv6) – Sean McMillan Aug 30 '11 at 21:52

5 Answers

up vote 3 down vote

People who are good at time management say you should work from a "prioritized to-do list". I've found that the same approach works for software features. You can make a big to-do list, but then put the high priority, high payback items at the top, and do those first.

As long as you re-prioritize regularly, the low value items won't ever be included.

Note that maintainability is a priority, so don't do quick hacks.

share|improve this answer
up vote 2 down vote

Somebody needs to have the courage to just say no: No to some off-the-wall request from a user that would destroy the architecture (assuming you do have an architecture), No to some itching internal desire to add a "feature" that was omitted in that first release, No to the huge itching internal desire to clean things up in that resulted from the rush to make that first release. Yep, that first release almost certainly had its share of ugly cruft. Sometimes you just have to live with it.

SCRUM may not help here because a lot of times second-system effect results from internal impulses. It is oftentimes easier to say no to some silly request from a customer than it is to say no to one of your developers, and it is even harder to say no to yourself.

share|improve this answer
1  
I agree with the need to say "no", but after the release rush, you need to clean things up and remove hacks before adding more features, otherwise technical debt will become too much sooner than later, and things that should take a day will take a week, and waste time exponentially from there. – wildpeaks Aug 30 '11 at 12:14
@wildpeaks: It's a fine line. The problem is that code always looks ugly, particularly to people on the inside, after it has sat around for a while. "If only we had designed it some other way ..." Resist the urge. (Besides, the new design will eventually look just as ugly as the old one.) – David Hammen Aug 30 '11 at 12:45
1  
Both good points, David and wildpeaks. Think the real answer is probably somewhere in the middle. We need to remove the emotion from the technical debt equation, make it more objective. – tenpn Aug 30 '11 at 13:06
I didn't mean hacks that look ugly, sorry if that wasn't clear, I meant the quick hacks added at the last minute to meet deadlines and that are slow as slugs or use way too much memory than it should, not prettyness of the design. In other words, the raptor-inducing hacks :-) – wildpeaks Aug 30 '11 at 14:34
up vote 1 down vote

I've been concerned by the second system effect a lot and the method that worked best for me was the value focused planning tool called The Scrum Product Backlog.

This tool is powerful to avoid the second system effect because you have to order your PBI (product backlog item) in a way to get high valuable items at the top, and the least valuable at the bottom.

The bottom of the product backlog are rarely converted in working software and PBI ordering has that secondary objective: minimizing waste (least or never used features).

In short I guess properly implement Agility can help you from getting a monster.

share|improve this answer
I agree the BPI is good, but I don't see how it really stops that "quick hack" solution. In fact it may worsen it, as you'll get through more backlog items if you go with that approach, but will end up with unmaintainable code at the end of it. But I guess maintainability is kind of in opposition to agility anyway? – tenpn Aug 30 '11 at 11:03
@tenpn: I don't think agility is in opposition of agility. Agility is a way of doing things, you can put your maintainability level yourself within the process. In fact Scrum is a framework and not a methodology. – user2567 Aug 30 '11 at 11:37
How do you enforce maintainability within agile then? How do I tell my product owner that I could be faster, but you'll see the benefit when future products are easier to construct? – tenpn Aug 30 '11 at 11:50
@tenpn: you don't have to tell anything to the PO. The team is responsible for that. – user2567 Aug 30 '11 at 12:03
up vote 1 down vote

You avoid it by not giving into the temptation to "hack" stuff into the existing codebase - there are no easy answers here.

Vet every new feature / requirement against the current system and architecture.

Does the new feature fit into the existing design? Great! Implement it correctly with all the right engineering approaches.

It does not fit into the existing design? Estimate how to re-architect the application to support the feature, and how long it will take. If the re-architecting is not feasible within the current timeframe get the feature dropped (explained with the re-architecting estimates).

share|improve this answer
up vote 0 down vote

We've found a very good remedy for this problem: SCRUM software development methodology.

In scrum, product owner is in charge of defining new features (alongside stakeholders and scrum team) and since he/she is usually somebody with less development and technical skill and more marketing analysis, he/she can simply avoid unnecessary features which lengthen the second project (the main reason behind second-system effect) and keep the time-to-market factor in mind.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.