4 ms·

That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making

by Kesty 14y ago

That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making them. But for programming ? You don't have those kind of costs.

coldtea 14y ago
>But for programming ? You don't have those kind of costs. Where did you get this strange idea from? You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.
- ubercow13 14y ago
  You don't have to ship until you have actually solved whatever problem you are working on, though. It still might be faster to get to the point of shipping code by this method, in some instances.
- jasonlotito 14y ago
  > You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff. None of which matter. The idea being if you are working on a component for version 2.0, even with all these "costs", it's better to iterate quickly. The only thing that is close to mattering is programmers' time, but even that is addressed in the article. Simply that it's faster to fail fast and iterate until you get the correct solution than it is to spend all that time planning.
  - notimetorelax 14y ago
    I think truth is somewhere in the middle. Even fast iterations must be planned and thought through. [1] [1] http://www.infoq.com/interviews/agile-software-architecture-zitzewitz http://www.infoq.com/interviews/agile-software-architecture-...
fnordfnordfnord 14y ago
>That's true if you are building something tangible. In product (prototype) development, there's a maxim that's followed by a lot of people "Plan to throw the first one away" or something to that effect. Sure, it may not work for every case. But, for lots of projects, it's useful to accept the notion that you will learn enough building the first one to get more value out of throwing it away than by keeping it. There are just too many things that can't be seen without a (probably) unattainable level of diligence.
prof_hobart 14y ago
You do. The scale of those costs, and whether those costs outweigh the cost of planning everything before you start, may vary depending on a variety of things, such as the structure of your development teams. But there's always a cost. At the simplest level, 5 days of coding something that you realise doesn't do what you want is 5 days you'll never get back. At places like mine, where you've got multiple third parties that you're interfacing with, sending them off to develop something before being 100% certain that they are doing the right thing could - and reasonably frequently does - have many thousands of pounds of cost implications, and many months of delay, when you realise that a particular call needs to real time instead of batch for example.

by Kesty 14y ago

coldtea 14y ago

>But for programming ? You don't have those kind of costs. Where did you get this strange idea from? You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.

ubercow13 14y ago
You don't have to ship until you have actually solved whatever problem you are working on, though. It still might be faster to get to the point of shipping code by this method, in some instances.
jasonlotito 14y ago
> You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff. None of which matter. The idea being if you are working on a component for version 2.0, even with all these "costs", it's better to iterate quickly. The only thing that is close to mattering is programmers' time, but even that is addressed in the article. Simply that it's faster to fail fast and iterate until you get the correct solution than it is to spend all that time planning.
- notimetorelax 14y ago
  I think truth is somewhere in the middle. Even fast iterations must be planned and thought through. [1] [1] http://www.infoq.com/interviews/agile-software-architecture-zitzewitz http://www.infoq.com/interviews/agile-software-architecture-...

fnordfnordfnord 14y ago

>That's true if you are building something tangible. In product (prototype) development, there's a maxim that's followed by a lot of people "Plan to throw the first one away" or something to that effect. Sure, it may not work for every case. But, for lots of projects, it's useful to accept the notion that you will learn enough building the first one to get more value out of throwing it away than by keeping it. There are just too many things that can't be seen without a (probably) unattainable level of diligence.

prof_hobart 14y ago

You do. The scale of those costs, and whether those costs outweigh the cost of planning everything before you start, may vary depending on a variety of things, such as the structure of your development teams. But there's always a cost. At the simplest level, 5 days of coding something that you realise doesn't do what you want is 5 days you'll never get back. At places like mine, where you've got multiple third parties that you're interfacing with, sending them off to develop something before being 100% certain that they are doing the right thing could - and reasonably frequently does - have many thousands of pounds of cost implications, and many months of delay, when you realise that a particular call needs to real time instead of batch for example.