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.
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.
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.
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.
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!'
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.
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.
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.
This is a total bullshit when it comes to software development in real world. If you write software to measure a temperature in your own house, maybe you can use this methods 🤣
This is such a great talk. Thanks to Greg and the organizers of this talk.
Glad you enjoyed it!
Do you have any other topics on mind that you would like to hear more on?
❤
Great legacy = transmitting micro debts !
The whole talk is great, pure wisdom.
Thanks for sharing
Thank you for taking the time to watch, like and comment. Means a lot!
that's why goos, it takes this idea messages passing and showcases it.
always thankful to these authors...
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.
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.
I'd make this talk mandatory to watch for every software developer.
Putting this as a part of our onboarding "must watch" as we speak 🫡
@@tretton37abwhen was this talk recorded btw?
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.
Wow! This is the talk I need to give my team!!!
This comment sparks so much joy
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.
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!'
Great comment! 💚
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.
Yay! Greg lives!
Yeah boi!
it's like my ideas put forward in better way...
same thing i realized, 12:37
thanks...
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
Facts!
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.
My reply here will be the number 1 words of choice for when we talk about the time frame or the outcome of a project - "It depends".
"Your tools affect your code". Exemplified by 'The medium is the message'. Mcluhan was right.
true story
Unix philosophy 30 years ago? More like 50 years ago
How about we say 70 and shake on it? :D
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.
nice bullsjit. We all know know we should drink more water, but all give a shit!
This is a total bullshit when it comes to software development in real world. If you write software to measure a temperature in your own house, maybe you can use this methods 🤣