The problem I see is that the tech debt often lives in the in-betweens, in the contracts between services, in the models being passed around. I would like to see a more concrete discussion of what it looks like to reorganize a 17,000 line monolith into deletable, one week chunks.
With the help of EDA and modularity this can be achieved. But the key challenge (and this also applies to balls of mud in general) is visibility of what should happen. Once you have that visibility you can bolt on additional functionality and remove old functionality at your will.
It help to have a team/project where the aim is to modernise the software. If you are chasing and rewarded only for making features, even if it takes 6-12 months pr little feature, you will not be able to.
Geat talk!! Greg again confirmed that in IT there is too much teenager-like attitude 'won't learn from elders - my world is very different. Let's invent!'
I can't count the times I've worked on systems where loose coupling, and no proper data definitions and typing in event buses led to spaghetti that goto spaghetti soup could only hope to emulate. These kinds of systems often rely on anecdotal hearsay and lived memory as documentation systems, and debugging prod logs lead to a bunch of "oh yeah, I remember now!" Sure, it's easy to rewrite little modules/actors/microservices in schemaless, loosely coupled software - but with each rewrite, something of the original intent and lived knowledge will be lost. This is more akin to credit card debt, or high-interest rate variable mortgage.
It would be nice to see this from the angle of entering an enterprise that already is overly-coupled and guiding improvements one small, deletable addittion / strangulation / wrapper / adapter at a time.
In an event sourced system, does anyone know how to delete the code and still enable replayability of events? Keeping around old models for replayability doesn't seem like a great idea, but how do you do it otherwise?
Great question! You've touched on a core challenge in event-sourced systems, tbh. The short answer for that would be "Event versioning" (meaning, we have to introduce new event versions for model changes, keeping old events compatible), "Upcasting" (transform old event versions to the current one on-the-fly, eliminating the need for old code) and "Archival" (archive obsolete models and events, using snapshots to capture system states). For the long one, we need to ping Greg 😅
here's an excerpt from Greg's book "Versioning in an Event Sourced System" that may apply if I understood your question correctly : “How do I version behaviour of my system as my domain logic changes?” The thought here is when hydrating state to validate a command logic in the domain can change over time. If replaying events to get to current state how do you ensure that the same logic that was used when producing the event is also used when applying the event to hydrate a piece of state? The answer is: you don’t.” it's in General Versioning Concerns > versioning of behaviour
Writing small programs inside a a big program is ok and not a new idea. But, overhead of managing and understanding too many small connected programs is still complex.
I don't buy this. The idea that you write a ton of small programs such that they aren't interdependent upon each other is not practical for most applications. Any sufficiently complex program will have dependencies such that when X changes, you also have to change Y. In the worst case, this cascades and now you have to change A, B, and C.
As Greg suggests, small programs have more advantages than disadvantages, but things are not that much simple always and also things are not viewed technically always.. Programs size and in other words programs boundaries are political aspects in many companies… To be happy with it or not, it happens that around programs some form of ownership is created.. Finally, programs size are in most cases further than just a technical issue
Much truth in there. However, not all debt is contained within one one-week bit. Then fixing that is not just a week. And when the behavior of the system emerges from the connection of small bits of behavior that's also nothing to rewire within one week.
Won't help. They will listen to it on 2x speed, pretty much the same like they read only first page of Royce's at best. Most never bothered to find it.
