16

On one hand there is an advice that says "Build one to throw away". Only after finishing a software system and seeing the end product we realize what went wrong in the design phase and understand how we should have really done it.

On the other hand there is the "second-system effect" which says that the second system of the same kind that is designed is usually worse than the first one; there are many features that did not fit in the first project and were pushed into the second version usually leading to overly complex and overly engineered.

Isn't here some contradiction between these principles? What is the correct view over the problems and where is the border between these two?

I believe that these "good practices" are were firstly promoted in the seminal book The Mythical Man-Month by Fred Brooks.

I know that some of these issues are solved by Agile methodologies, but deep down, the problem is still the principles still stand; for example we would not make important design changes 3 sprints before going live.

gnat
  • 21,442
  • 29
  • 112
  • 288
Random42
  • 10,370
  • 10
  • 48
  • 65
  • 3
    Personally I think you need three -- one to understand the basics of the problem, two to understand the advanced stuff and a third to get it right. – Wyatt Barnett Nov 15 '12 at 00:11
  • 5
    @Wyatt: I my case the correct number to "get it right" is n+1, n being the current iteration – mattnz Nov 15 '12 at 00:39

2 Answers2

24

Build one to throw away comes from "not knowing what you don't know" at the start, so you learn as you go what you should have done at the start.

Second System Effect comes from "now knowing what you did not know, however not knowing what you still don't know" i.e. Second system effect comes from trying to build a bigger, shinier, more complex system than the first one, without the knowledge needed at the start - sounds a lot like what happens with the first system.

Therefore second system effect is not contradiction. Building a second system to the same functionality as the first is (to my knowledge) never done. The second system always has to be "better", therefore more complex, therefore substantially similar problems to the first system are expected - that should be thrown away.

So build one to throw away, throw it way and build it again with no scope enlargement, and you won't have a second system problem. (This tends to be done more often on planets with purple skies, pink seas, and flying pigs.)

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • Isn't "the first system, that will be thrown away" a prototype? If this is true, as far as I know, the prototype usually doesn't have the full functionality of the tend product; or at least in the context of a throw-away prototype. – Random42 Nov 15 '12 at 06:52
  • That's why you should refactor heavily in later sprints, throwing away your initial attempts at solving the problem as new requirements get uncovered on your product backlog. – Joeri Sebrechts Nov 15 '12 at 09:42
  • @Joeri Sebrechts Refactoring does not mean throwing away the first system; also you cannot refactor wrong requirements or bad architecture... – Random42 Nov 15 '12 at 12:37
  • The only thing that I have to add to this answer, just for explicit clarity, is that the second system refers to a second production system. – Thomas Owens Nov 16 '12 at 14:22
0

The problem you are referring to means that several things were skipped, hence the resulting system went wrong. Let me describe some of the missing steps:

Quality Management - Do it right the first time! Never use any temporary hacks, or temporary compromises. There shall be no rework needed. All resources are used efficiently and everything you do is a proper contribution to the project.

Feasibility Analysis - Discover business need. Create a business case for the project.

Project Plan - Clearly define your initial scope, plan how the solution will be delivered, create a baseline, stick to the plan. Don't spend time on anything that's not on the critical path.

Requirements Engineering - Elicit business requirements (i.e. capture business processes and determine what business operations should be supported by the computerized system, translate 1:1 business operations to system use cases). Validate & verify! (are we building the right thing? Are we building the thing right?) All requirements must be linked to the original business need.

Software Design - Translate use cases and domain model into component design and solution architecture. All components must be linked to the requirements from RE.

Implementation - Code the software as in the design. All code must be linked to components from SD.

Validation - Unit testing, integration testing, performance, ... (all use cases from RE will now need to be tested)

These are some key aspects of a software process. Mentioned activities are part of Software Engineering. This is how you build the right software solution for the real business need, and you build it on time, on budget, to specification.

Look up these terms to build better software and to get it right the first time:

  • Feasibility Analysis (esp. how to build a Business Case)
  • Project Management (esp. Project Plan and Risk Register with Risk Mitigation)
  • Requirements Engineering (elicitation, analysis, specification, validation)
  • Software Design (UML and component-based software engineering)
  • Software Construction (design patterns, frameworks, defensive programming)
  • Software Validation (unit testing, UAT, etc.)
  • 1
    There will always be need for rework as requirements change. But in well-designed systems these reworks can be done incrementally and cleanly without affecting unrelated parts. – JesperE Nov 16 '12 at 14:55
  • Dream on. You expect the customer to know in advance what he wants/needs. This does not happen; that's why we have agile methods. – Martin Schröder Nov 16 '12 at 18:44
  • In other words, there only needs to be a change in sw when the company's business process changes and that doesn't happen so often. –  Nov 16 '12 at 23:22