First published June 2009. I still see folks making this mistake—”design good APIs”. Sure, fine, but what about when the APIs turn out not to be good? Or they were good but now they’re not? In addition to drawing boundaries between elements, we need to also be prepared to periodically re-draw those boundaries. I think this is difficult because re-drawing often crosses team boundaries, creating mis-aligned incentives (calling team needs the change but the called team has other priorities). I address cross-team design in the followup to
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).
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.
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).
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.
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.