My team is also rebuilding a big legacy system. We decided to rebuild because paradigm shifts (eg shifting a responsibility to a different team) would unlock nonlinear business value vs refactoring that would have unlocked incremental value. I thought this seemed similar to the idea of revolutionary (paradigm shift) vs ordinary (incremental).
That analogy makes sense to me. The longer it takes to get production feedback from the work you're doing, the greater the risk. That risk may be worth it given the situation. But the risk is why my bias is towards incremental rewrites.
With my team a few years ago we experienced with something very similar to what you call Revolutionary Design, and for basically the same purpose. We called that codequakes, (for the pun on earthquakes) and played with a scale like richter scale for amplitude of the changes.
We are currently rewriting a massive and messy legacy code. We didn’t go with isolating the existing code in terms of refactoring them into a replaceable unit but rather only “identifying” them and introduce the new design as A/B experiment.
We could not afford to invest time in isolating the old code out because it would delay the time to market of functionalities in new design. Like you mentioned, it is harder burden on us which we chose to accept for sake of earlier delivery of new features.
That seems in line with what I advocate in TF?. It's messier, in that you have both codebases in production at the same time, but you avoid the 2 big mistakes of software design--completely halting feature work & the big switch when you put a whole bunch of new code in production at once.
Isn't OCP based on the behaviour though? e.g. Open to extending behaviour not modifying it.
So in this case revolutionary is changing that behaviour, which will mean an entirely new set of classes and functions and maybe even structure. It's new so create a new thing that encapsulates the new behaviour. When that's done you can make the decisions on if the old behaviour is even needed (e.g. delete or keep). This is how I understood it at least. So you are never breaking any expected behaviour, only ever extending it or creating new behaviour.
When I say expected behaviour I'm talking about from the view point of the actor. So if HR and finance both use a Salary Service class and I change the behaviour for Finance and break something for HR, then thats breaking OCP and SRP. So I extract those into their own services and the single salary service is now a composite facade. Now the individual classes have behaviour specific for the actor that uses it. Now I can ask the question "Is this new feature changing the behaviour". If yes then thats an entirely new class. It may replace the Salary Service or live next to it.
Revolutionary approaches in software development is not only violation of OCP but also is against of incremental design. Plus, it often ends in higher cost. Ofc, OCP is evolutionary design not revolutionary! Better to have this in mind.
Design in advance of need is waste.
I kinda want to print this out and stick it up around my work place 😂
My team is also rebuilding a big legacy system. We decided to rebuild because paradigm shifts (eg shifting a responsibility to a different team) would unlock nonlinear business value vs refactoring that would have unlocked incremental value. I thought this seemed similar to the idea of revolutionary (paradigm shift) vs ordinary (incremental).
That analogy makes sense to me. The longer it takes to get production feedback from the work you're doing, the greater the risk. That risk may be worth it given the situation. But the risk is why my bias is towards incremental rewrites.
With my team a few years ago we experienced with something very similar to what you call Revolutionary Design, and for basically the same purpose. We called that codequakes, (for the pun on earthquakes) and played with a scale like richter scale for amplitude of the changes.
Link to `Design is an island`: https://web.archive.org/web/20120220120210/http://www.threeriversinstitute.org/blog/?p=122
We are currently rewriting a massive and messy legacy code. We didn’t go with isolating the existing code in terms of refactoring them into a replaceable unit but rather only “identifying” them and introduce the new design as A/B experiment.
We could not afford to invest time in isolating the old code out because it would delay the time to market of functionalities in new design. Like you mentioned, it is harder burden on us which we chose to accept for sake of earlier delivery of new features.
That seems in line with what I advocate in TF?. It's messier, in that you have both codebases in production at the same time, but you avoid the 2 big mistakes of software design--completely halting feature work & the big switch when you put a whole bunch of new code in production at once.
Isn't OCP based on the behaviour though? e.g. Open to extending behaviour not modifying it.
So in this case revolutionary is changing that behaviour, which will mean an entirely new set of classes and functions and maybe even structure. It's new so create a new thing that encapsulates the new behaviour. When that's done you can make the decisions on if the old behaviour is even needed (e.g. delete or keep). This is how I understood it at least. So you are never breaking any expected behaviour, only ever extending it or creating new behaviour.
When I say expected behaviour I'm talking about from the view point of the actor. So if HR and finance both use a Salary Service class and I change the behaviour for Finance and break something for HR, then thats breaking OCP and SRP. So I extract those into their own services and the single salary service is now a composite facade. Now the individual classes have behaviour specific for the actor that uses it. Now I can ask the question "Is this new feature changing the behaviour". If yes then thats an entirely new class. It may replace the Salary Service or live next to it.
Revolutionary approaches in software development is not only violation of OCP but also is against of incremental design. Plus, it often ends in higher cost. Ofc, OCP is evolutionary design not revolutionary! Better to have this in mind.