Optimise for continuous change, not modernisation or legacy
Posted by ArtisticProgrammer11@reddit | programming | View on Reddit | 8 comments
Posted by ArtisticProgrammer11@reddit | programming | View on Reddit | 8 comments
manifoldjava@reddit
While good software should be maintainable, “optimizing for change” is rarely achievable in practice. Beyond the fundamentals such as low coupling, high cohesion, and clean separation between public APIs and internal implementation, attempts to design for an unknown future often lead to over-engineering or endless deferral.
In my experience, it’s better to focus architectural effort on solving the problem at hand with clarity and sound boundaries. If your software succeeds, the real pressures for change will come from directions you couldn’t have predicted, and no amount of preemptive design would have made those changes simple or desirable anyway.
The goal isn’t to predict change, but to make change possible when it arrives.
uep@reddit
I basically agree with this premise. Optimizing for change allows modernization to come gradually. I'd like to think that full rewrites are known to be disasters by now. Modernization shouldn't necessarily be a goal in itself, which I think is the case this article is making.
In my opinion, a big reason so much stuff ends up as "legacy", is that every project needs a postmortem after release. Crucially, time needs to be allocated to prioritize refactoring and cleanup tasks. Sadly, in my years working, I've never seen this done at the companies I work at. As a result, everything ends up being so fragile that people are afraid to change anything, so you end up with many copies of code with the same purpose. Good unit tests and a process built around them can help with that, but sadly, in my domain this is also rare.
I personally believe that code ownership has strong affects both positive and negative on these efforts. What those affects are is strongly biased by my personal opinions though.
MrLyttleG@reddit
My last big project was to rewrite the entire old platform because it was impossible to upgrade and even to fix the slightest bug given the pile of spaghetti that has accumulated over time. The functionality was taken over, the database initially too and over time we were able to evolve the base model and rewrite the platform calmly adding lots of features. We went from vbnet aspx code to dotnet core blazor wasm and it runs flawlessly, customers are generally satisfied
All_Up_Ons@reddit
Full rewrites don't have to be a disaster. They just have to be taken seriously and be for the right reasons. If your releases take weeks or months due to legacy bloated architecture, a rewrite into an architecture that allows teams to do separate daily deployments may be the only way to stay competitive long-term.
sheep1e@reddit
I agree with that - I’ve been involved in a few successful rewrites - but the common advice against them comes from the fact that there tend to be many more ways for them to go wrong than right. To guard against that you need the right resources and capabilities, which companies often simply don’t have.
_xGizmo_@reddit
Out of curiosity, what's your domain?
max123246@reddit
Not sure what theirs is but I'm in GPU programming and it sounds about right. I've seen so much code just copy pasted from project to project. I try to do my part against it but sometimes I understand why because we don't have nearly enough regression testing
Fishi_g@reddit
Care to share your thoughts to me new vid? vid