 Something I see a lot of software reviewers praise various software on is the amount of configuration it provides. And I see this as a really, really huge thing, an open-source software where they're praising how much configurability things have. That's especially the case with software part of the two big desktop environments, GNOME and KDE. Where GNOME's been changing recently, but they still both seem very obsessed with as many configurations as absolutely possible. And you see settings throughout, almost everything that there is, tons of settings. You ever use an IDE, instead of just like a text editor with syntax highlighting, you definitely see this. They are absolutely insane. Really wish somebody would make a reduced-down version of Visual Studio, and now I don't mean VS Code. I mean like same plugins, but a static interface that doesn't... oh my god. But anyways, I'm going to take quite a different stance. Rather, configuration is the root of all evil. Evil in this context being code complexity, because code complexity is the single biggest headache you're going to have as a developer. That's developer specific. I'm not counting Office Politics, but so that was configuration, settings, or the root of all evil. Now I've lifted this from something I've written from, and something else. Something I was basically contracted to write sort of a show assistant bot for somebody. It was not written, and I had very, very limited constraints with what I could work with. Even the machinery that would be running on was just remarkably constrained. So I've lifted the part of that I want to show over here into IDA. Mostly because that is basically somebody else's property, even though I'm on the copyright holder. I can get away with it, but I'd rather not. But also that IDA is quite a bit more readable, and I've been doing all my other stuff in IDA, so I would like to stick to using IDA for this. Because I'm just trying to provide a demonstration, especially for newer programmers who might get a little carried away with this, and run into a problem like I did, but without the tools to help manage it. So what we have here is, I believe, 19 various settings, and those settings have a different amount of options available to them. Some are just simply on-off, true-false. I could have just used bullions, but I'm trying to keep this a bit orthogonal. Some of them have up to five options, so four on-states and one off. And some of them are just two or three on-states, and the one off. They all have an off. So you might be saying, well, that's not too bad. You need to test for 19 different things. No. No, actually. This is a case of, what do they call it in math class? A combinatorial or something like that. Let's pull up a calculator and... So let's just tally up how many different combinations of settings there are. And this is pretty straightforward to do. It's just multiplying all the different options available together. So we have five for the first one, five for the second one, two for the third one, two for the fourth one, and so on. Left off at 11. So that's 92 million. 160,000 different combinations of these settings. And that would be the extent of the complexity here if there were only one thing these were all modifying. Say like, if these were all used to modify the view of something, you know, the presentation of, say, part of an app, then that would be the actual complexity we have. But that's not what we're dealing with. These are all used to modify a rather large data structure and essentially to decide what's present in the data structure and what's not, even though technically they all are always, it's sort of like changing them from being publicly visible to privately visible, or not publicly visible. This was justified complexity, essentially. Something I was willing to deal with and it was because I had the tools available. Basically, this code is part of an assistant bot of sorts that is being used to help out with a type of show. And because for any type of show you're not always willing to do everything that you're willing to do with a broad sense. You know, a certain show you might not want to do certain things. We use comedy as an example. Say you're feeling a little under the weather, you're recovering from an illness, but you're not fully together yet. You might not be wanting to do physical comedy like, say, slapstick stuff. But stand up is still fine. All of these settings are involved in fine grain control over what would be done, what is acceptable for others to suggest during the show, basically. So this was justified in my opinion, but what we... The total menu of sorts is actually 85 items. Remember what I said about this being the case? If it was one item, such as a view that it was changing, but actually changing the state of 85 different items, we have 7,833,600,000 different combinations that need to be tested from 19 settings and 85 items in a menu. Complexity can spiral out of control remarkably quickly. Now, like I said, there are ways of dealing with this kind of complexity, and I will get to that in another video. I'd like to just leave this one as a basic, like, hey, here's what you need to worry... Here's why you need to worry about settings and adding too many settings, because it can and absolutely will spiral out of control. Even if you do have the tools to help keep these types of things more manageable, the thing is they still do reach an absolutely insane level of complexity. The tools for managing these types of things do not reduce the amount of test cases you need to write at all. They merely make the code itself easier to work with, and you still have the exact same amount of test cases that need to be tested. Unless you've got some type of automatic unit test generator written out, nobody's going to write that many unit tests. So, this is a little bit of a controversial opinion, but hopefully you found this video at least informative, something to keep in mind even if you are going to be introducing a large amount of settings. Just be...at least be aware and make an informed decision about the trade-off if you're willing to take on the increased complexity, and obviously I was doing all this massive amount of stuff, so it's not like I'm saying never do it. Hopefully this video helps you go in making informed decisions about the level of complexity that you can be introducing into your code and how you can quickly reach a point where things are no longer reasonably testable, which is obviously not good. That's when you have to start relying on interesting development methodologies that involve using your customer base to test the product. And I can get bad. I can get bad. But if you have found this video helpful, please give me a thumbs up. If you like what I do in general, please consider subscribing, maybe even hit that little notification bell that appears because it gets notifications, that's why it's called a notification bell. Have a good one, guys.