Incidental vs. Accidental Complexity

[00:00:00]
>> David Khourshid: So now we're going to jump to the second lesson, which is on diagrams. So you might be asking yourself like, what do diagrams really have to do with this? I thought that we're going to be working in React, and the main point of, or the main motivation of modeling your application is to separate incidental versus accidental complexity.

[00:00:27]
And so what is the difference between incidental and accidental complexity? Incidental complexity is unavoidable. This is the irreducible complexity that comes from the problem domain that you're working in itself. So it is how things are supposed to update the different flows, where data comes in from, etc. It doesn't matter which language or framework or libraries you're working on, this incidental complexity is going to stay exactly the same and you really can't do much to reduce it.

[00:01:01]
But that's not a huge problem, as we'll see. The second part is accidental complexity. So this is the complexity that we ourselves introduce from the implementation choices we make, the different tools or libraries or frameworks that we use. Earlier, someone mentioned as part of their struggles with state management that for example, Redux.

[00:01:25]
And this could happen with other tools too. But Redux, at least the original Redux sort of mandated that you have so many different files. I remember when I worked in Redux you had this actions file and then you had your reducer file and then you had maybe another file for constants and maybe another file for selectors.

[00:01:43]
And that I would call accidental complexity. Because this is again self inflicted. We chose Redux, at least the old version. Redux toolkit is a lot better now, but it introduced a lot of complexity where we basically have to play nice with the tools we use rather than focusing on the actual problem domain that we're working in.

[00:02:07]
Another one that was mentioned was many use dates. So we have all of these use date calls and then we have to juggle them and also chaining of useEffects. So our decision to use many useEffects actually contributes to accidental complexity over incidental complexity. And so this is why I think it is super important to model your application.

[00:02:31]
So what do I mean by modeling? I don't mean just trying to use some sort of advanced tool to specifically model or do anything like UML, just to make sure that you have everything perfect before you start working. Just because, like we talked about, that's not how code works, that's not how our projects work.

[00:02:52]
We might be jumping into legacy projects where that kind of documentation doesn't exist. So that's why I really want to emphasize quick documentation, where you're basically just writing down in whatever is the most like, the fastest, most optimal way of describing your application logic. Just documenting the different flows, how your data works, etc.

[00:03:19]
And so that's why in this exercise, we have a flows ND file. It's empty but this is something where I want you all to brainstorm and work on after we learn about the different diagrams.