Fork me on GitHub
David Pham05:06:39

Are there rationales on to why event driven systems are bad? (Referring to David Nolen talk on OM Next)


IMO: they are not “bad” per se….but just like any tool they can be a bad choice for a situation


I’m working on an episode of the Clojurescript podcast where I say more about that with respect to Fulcro…but the TL;DR: event systems are great for decoupling things (I wrote a button, you want to hook a callback to it). They lead to incidental complexity when used in large programs because of the decoupling: They are hard to trace, side effects can be invisibly hooked to them, code becomes fragile during evolution because all of those potential side effects are hard to reason over. Thus, for example, one team member might remove a dead feature that had a side effect that some other feature accidentally relied upon (I’ve seen it happen). Now that other thing is broken and it is hard to figure out why (and your end users are often the people that find the problem). Events are not traceable through your IDE, either. If you compose functions or function-like things, then the code is easy to reason about locally at each layer of abstraction. But of course it is coupled. The pro/con, from my perspective, is do you need the decoupling for a real purpose in the program (i.e. the button example where you ahve no access to the code of the button, but need to be able to hook to it)? As with any development approach: there are pros/cons to each. I personally think the sustainability of event systems can become quite poor in large systems that are worked on by teams of people. Small projects where one person builds it and knows the whole thing can be quite nice in event-based systems. Also, large projects with good developer discipline and rules (which rarely get followed perfectly, so we’re a bit in candyland now) can be fine with any tool: You say things like: “these kinds of events must not side effect”, or “events must be local to a code module”. You can do it, and you can get a great result.

👍 8

IMO here are the things that matter: 1-10: Do you have a good team, and do they have emotional safety? Can they point out a problem without getting squished? Can they express an opinion without poor treatment? Do you practice continual improvement? Does management give you time to fix problems that need refactoring? Is your organization led around by “sales people taking orders”? etc. 11: Do your tools encourage scalable patterns over time? If you get 1-10 right, then 11 becomes salient. If you don’t get 1-10 right, then you’re screwed no matter what you pick. Use Java and Spring…at least you can hire replacements when your team members quit, which they will…frequently.

❤️ 12
👍 4

And if you get 1-10 right, 11 is nice, but you’ll naturally evolve it as a team…it’ll just take more time, and your initial choices (i.e. Java+Spring) might have real overhead that you can’t easily get around.