5 ms·

The current trend in software architecture is called "Sacrificial Architecture" by Fowler: http://martinfowler.com/bliki/SacrificialArchitecture.html http://mar

The current trend in software architecture is called "Sacrificial Architecture" by Fowler: http://martinfowler.com/bliki/SacrificialArchitecture.html http://martinfowler.com/bliki/SacrificialArchitecture.html . You don't even try to "evolve" software but periodically rewrite it which "solves" the "Paradoxes of Software Architecture" in one fell swoop. Disposable instead of durable software.

innguest 12y ago
Alan Kay has been saying that at least since the 1970's, but the likes of Joel Spolsky have always argued against it. Now comes Martin Fowler to tell us that Alan Kay was right, without crediting him, of course.
- jalfresi 12y ago
  Thats interesting, any links where I can find out more of Alan Kays ideas on this subject?
  - innguest 12y ago
    Alan Kay famously went through several iterations of rewriting the first Smalltalks from scratch and he is a big believer in that approach. I don't know if it's easy to find him talk about that explicitly but here's one example: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 > AK I had the world’s greatest group [in the Smalltalk era], and I should have made the world’s two greatest groups. I didn’t realize there are benefits to having real implementers and real users, and there are benefits to starting from scratch every few months. I'd recommend his talks at OOPSLA or anything you can find on YouTube. Especially 'The Computer Revolution Hasn't Happened Yet' is a gospel for contrarians.
- pluma 12y ago
  To be fair, the idea itself is much older. It actually reminds me of the Japanese approach to mastery: do something, do the same thing again, repeat until you have mastered it.
pan69 12y ago
I think this is so true. When you have an evolving system, just toss it out every few years and rebuild from scratch. Obviously, this only works if the people who are building the new version have also build the previous version, i.e. it's the people with the knowledge of the system that's reusable and precious, the code is disposable.
Chris_Newton 12y ago
Isn’t that just a new buzzword for something experienced developers have always done? Each time you perform maintenance on any existing piece of software, you necessarily rewrite it to some extent. The rest is just a matter of scale. Maybe you make a small change in a logical expression or modify a control structure. Maybe you reimplement an entire function using a new algorithm, or redesign a whole module with different internal data structures. Maybe you rebuild the whole system with the extra N years of insight you have gained from how the previous one worked plus knowing about N more years of evolving requirements than you did last time around. One way or another, you are always looking for the scale where the benefits of rewriting the whole instead of adapting what is already there — in other words, instead of rewriting one or more smaller parts — outweigh the costs. If a project has reached the stage where the cost of working around an existing architecture is prohibitive, it’s time for a rewrite on an architectural scale.
- dllthomas 12y ago
  "Isn’t that just a new buzzword for something experienced developers have always done?" Yes. c.f. "Write it, throw it away, rewrite it." However, I'm not sure I agree with the rest of your post. It's certainly true - even tautological - that any change is a change of something. It is possible to change behavior without changing code, though (configuration), and it's possible to change code without changing architecture, and I think each of these things is somewhat different in kind not just degree.
  - Chris_Newton 12y ago
    I suppose it depends on how you define “architecture”. I usually take it to mean something along the lines of the properties of a software design that are difficult to change once determined and/or that potentially affect the entire code base and/or that are expected to last for a long time. Given some such definition, it is certainly very expensive to change architecture, and therefore relatively unlikely that you’d want to rewrite on such a sweeping scale. That still applies even if the architecture you’ve developed after a while isn’t what you’d ideally chose if you were starting over. I don’t really see any qualitative difference from any other large (but not that large) scale rewrite, though. To me it’s still just a quantitative cost/benefit question, albeit one where the cost is very high so you probably need to have some severe obstacle to overcome before the big rewrite is justified.
je42 12y ago
I'd say "you gotta do what you gotta do, but don't be lazy": 1. think before you do something. i.e. architect towards known knowns. 2. refactor when new information becomes available. Most people have a problem with 1 and just go blindly into random search, with the thought: "we can just try this; we can always refactor later" That is fine if you cannot predict the outcome. However, if you never try to become good at predicting outcomes you will get stuck in "lets try" mode. If you practice predicting outcomes i.e. architecture code/product ( 'think without actual coding'), you will find that more often it guides the way to the highspeed lane and allowing you skip a couple of "iterations/sacrifices" ( but obviously not all... )
- collyw 12y ago
  > Most people have a problem with 1 and just go blindly into random search, with the thought: "we can just try this; we can always refactor later" Or they leave out the refactor later part in my experience.
vog 12y ago
Note that this can only work if you divide your code properly into modules (or sub projects), where you separate the often-changing code from the rock stable code (and anything in between). Then, you rewrite mostly those modules which are subject to steady change. If you don't do this, you'll always have to rewrite the whole system at once, which becomes bigger over the years. So you would need more and more time and developers for each rewrite. In contrast, if you manage to always keep the amount of code you want to rewrite at a reasonable size, this approach may become workable over years.

innguest 12y ago

Alan Kay has been saying that at least since the 1970's, but the likes of Joel Spolsky have always argued against it. Now comes Martin Fowler to tell us that Alan Kay was right, without crediting him, of course.

jalfresi 12y ago
Thats interesting, any links where I can find out more of Alan Kays ideas on this subject?
- innguest 12y ago
  Alan Kay famously went through several iterations of rewriting the first Smalltalks from scratch and he is a big believer in that approach. I don't know if it's easy to find him talk about that explicitly but here's one example: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 > AK I had the world’s greatest group [in the Smalltalk era], and I should have made the world’s two greatest groups. I didn’t realize there are benefits to having real implementers and real users, and there are benefits to starting from scratch every few months. I'd recommend his talks at OOPSLA or anything you can find on YouTube. Especially 'The Computer Revolution Hasn't Happened Yet' is a gospel for contrarians.
pluma 12y ago
To be fair, the idea itself is much older. It actually reminds me of the Japanese approach to mastery: do something, do the same thing again, repeat until you have mastered it.

pan69 12y ago

I think this is so true. When you have an evolving system, just toss it out every few years and rebuild from scratch. Obviously, this only works if the people who are building the new version have also build the previous version, i.e. it's the people with the knowledge of the system that's reusable and precious, the code is disposable.

Chris_Newton 12y ago

Isn’t that just a new buzzword for something experienced developers have always done? Each time you perform maintenance on any existing piece of software, you necessarily rewrite it to some extent. The rest is just a matter of scale. Maybe you make a small change in a logical expression or modify a control structure. Maybe you reimplement an entire function using a new algorithm, or redesign a whole module with different internal data structures. Maybe you rebuild the whole system with the extra N years of insight you have gained from how the previous one worked plus knowing about N more years of evolving requirements than you did last time around. One way or another, you are always looking for the scale where the benefits of rewriting the whole instead of adapting what is already there — in other words, instead of rewriting one or more smaller parts — outweigh the costs. If a project has reached the stage where the cost of working around an existing architecture is prohibitive, it’s time for a rewrite on an architectural scale.

dllthomas 12y ago
"Isn’t that just a new buzzword for something experienced developers have always done?" Yes. c.f. "Write it, throw it away, rewrite it." However, I'm not sure I agree with the rest of your post. It's certainly true - even tautological - that any change is a change of something. It is possible to change behavior without changing code, though (configuration), and it's possible to change code without changing architecture, and I think each of these things is somewhat different in kind not just degree.
- Chris_Newton 12y ago
  I suppose it depends on how you define “architecture”. I usually take it to mean something along the lines of the properties of a software design that are difficult to change once determined and/or that potentially affect the entire code base and/or that are expected to last for a long time. Given some such definition, it is certainly very expensive to change architecture, and therefore relatively unlikely that you’d want to rewrite on such a sweeping scale. That still applies even if the architecture you’ve developed after a while isn’t what you’d ideally chose if you were starting over. I don’t really see any qualitative difference from any other large (but not that large) scale rewrite, though. To me it’s still just a quantitative cost/benefit question, albeit one where the cost is very high so you probably need to have some severe obstacle to overcome before the big rewrite is justified.

je42 12y ago

I'd say "you gotta do what you gotta do, but don't be lazy": 1. think before you do something. i.e. architect towards known knowns. 2. refactor when new information becomes available. Most people have a problem with 1 and just go blindly into random search, with the thought: "we can just try this; we can always refactor later" That is fine if you cannot predict the outcome. However, if you never try to become good at predicting outcomes you will get stuck in "lets try" mode. If you practice predicting outcomes i.e. architecture code/product ( 'think without actual coding'), you will find that more often it guides the way to the highspeed lane and allowing you skip a couple of "iterations/sacrifices" ( but obviously not all... )

collyw 12y ago
> Most people have a problem with 1 and just go blindly into random search, with the thought: "we can just try this; we can always refactor later" Or they leave out the refactor later part in my experience.

vog 12y ago

Note that this can only work if you divide your code properly into modules (or sub projects), where you separate the often-changing code from the rock stable code (and anything in between). Then, you rewrite mostly those modules which are subject to steady change. If you don't do this, you'll always have to rewrite the whole system at once, which becomes bigger over the years. So you would need more and more time and developers for each rewrite. In contrast, if you manage to always keep the amount of code you want to rewrite at a reasonable size, this approach may become workable over years.