3 ms·

I like Brooks' "plan to throw one away; you will, anyhow.": This [first] system acts as a "pilot plan" that reveals techniques that will subsequently cause a c

I like Brooks' "plan to throw one away; you will, anyhow.": This [first] system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system. However, in practice I'm not confident enough in my understanding, and fear losing all that hard-won work, so I refactor too. A rewrite from scratch is probably more viable when the project is small enough to keep in your head at once.

RangerScience 6y ago
Good architecture is pretty much just about slicing things up so that rewrites / refactors can happen incrementally, rather than all at once. This can actually go both bottom-up (these functions are easy to re-arrange and don't need a rewrite) and top-down (these functions suck, but I don't have to rearrange anything to replace them). "Good architecture is the one that allows you to change."
- cratermoon 6y ago
  What if you slice it up wrong?
  - RangerScience 6y ago
    Then you're gonna have a shit time of it, and may need to do a total rewrite, instead of an incremental one.
titanomachy 6y ago
Brooks has since amended this[1] to say that he really meant it in the context of traditional "waterfall" development, where the first iteration is meticulously planned and designed as a whole system before any code is written at all. Rapid, iterative prototyping, followed by refactoring, is a perfectly reasonable approach today. No need to create a fresh repository and rewrite all code from scratch. David Heinemeier Hanssen, creator of Rails and a big advocate of building working code as early as possible, wasn't even born in 1975 when the mythical man-month was written. Linus Torvalds was a (presumably) plucky 6-year-old. Brooks wrote that book for an audience that would have known waterfall as the only way. [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway
- hyperpallium2 6y ago
  wikiwiki seems to be having trouble moving to github. Here's wayback https://web.archive.org/web/20190821162524/https://wiki.c2.com/?PlanToThrowOneAway https://web.archive.org/web/20190821162524/https://wiki.c2.c... And the bit you referenced: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." You don't have to throw everything away. Like reusing libraries, you can reuse your modules, or whatever code you like. It's the part that is a tangled Gordian Knot that is easier to cut than meticulously unravel. "Starting with a clean slate" is a common idea in many contexts. One very similar to code is writing. You can hack and edit, but a fresh draft is easier (and safer) for fundamental conceptual and structural changes. BTW "Waterfall" was a parody of processes, though the conceptual aspects (requirements vs specifications etc) are useful. People then were just as intelligent as today. Maybe more.
  - titanomachy 6y ago
    I don't see waterfall as a product of limited intelligence but rather limited tools and history. It's natural that early software engineers would generalize processes from mechanical and chemical engineering, especially given the cost of iteration with early software tools.
mbreese 6y ago
We are talking about research code here. And from many of the comments, it seems like the biggest hurdle is not understanding requirements the first time around. This is incredibly common. I work in computational biology, and my normal thought process is that by default, you should expect to write the code three times (especially for less experienced developers). The first time, you don’t know the problem. The second time you’ve figured out the problem, but don’t know the best way to do it. The third time, you’ve figured out the problem and a decent strategy to solve the problem. With more experience, you can narrow that to just two iterations. But really, especially with research, you rarely have a good feel for the problem domain the first time around. And when you have the expectation that you’re going to throw the code away, you don’t get quite as hung up on implementation details for the first two rounds. And because of that, the process is easier. And you don’t have to worry about refactoring bad code. Just accept the first round as an experiment and take what you’ve learned about the problem to write better the next time.

RangerScience 6y ago

Good architecture is pretty much just about slicing things up so that rewrites / refactors can happen incrementally, rather than all at once. This can actually go both bottom-up (these functions are easy to re-arrange and don't need a rewrite) and top-down (these functions suck, but I don't have to rearrange anything to replace them). "Good architecture is the one that allows you to change."

cratermoon 6y ago
What if you slice it up wrong?
- RangerScience 6y ago
  Then you're gonna have a shit time of it, and may need to do a total rewrite, instead of an incremental one.

titanomachy 6y ago

Brooks has since amended this[1] to say that he really meant it in the context of traditional "waterfall" development, where the first iteration is meticulously planned and designed as a whole system before any code is written at all. Rapid, iterative prototyping, followed by refactoring, is a perfectly reasonable approach today. No need to create a fresh repository and rewrite all code from scratch. David Heinemeier Hanssen, creator of Rails and a big advocate of building working code as early as possible, wasn't even born in 1975 when the mythical man-month was written. Linus Torvalds was a (presumably) plucky 6-year-old. Brooks wrote that book for an audience that would have known waterfall as the only way. [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway

hyperpallium2 6y ago
wikiwiki seems to be having trouble moving to github. Here's wayback https://web.archive.org/web/20190821162524/https://wiki.c2.com/?PlanToThrowOneAway https://web.archive.org/web/20190821162524/https://wiki.c2.c... And the bit you referenced: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." You don't have to throw everything away. Like reusing libraries, you can reuse your modules, or whatever code you like. It's the part that is a tangled Gordian Knot that is easier to cut than meticulously unravel. "Starting with a clean slate" is a common idea in many contexts. One very similar to code is writing. You can hack and edit, but a fresh draft is easier (and safer) for fundamental conceptual and structural changes. BTW "Waterfall" was a parody of processes, though the conceptual aspects (requirements vs specifications etc) are useful. People then were just as intelligent as today. Maybe more.
- titanomachy 6y ago
  I don't see waterfall as a product of limited intelligence but rather limited tools and history. It's natural that early software engineers would generalize processes from mechanical and chemical engineering, especially given the cost of iteration with early software tools.

mbreese 6y ago

We are talking about research code here. And from many of the comments, it seems like the biggest hurdle is not understanding requirements the first time around. This is incredibly common. I work in computational biology, and my normal thought process is that by default, you should expect to write the code three times (especially for less experienced developers). The first time, you don’t know the problem. The second time you’ve figured out the problem, but don’t know the best way to do it. The third time, you’ve figured out the problem and a decent strategy to solve the problem. With more experience, you can narrow that to just two iterations. But really, especially with research, you rarely have a good feel for the problem domain the first time around. And when you have the expectation that you’re going to throw the code away, you don’t get quite as hung up on implementation details for the first two rounds. And because of that, the process is easier. And you don’t have to worry about refactoring bad code. Just accept the first round as an experiment and take what you’ve learned about the problem to write better the next time.