Stovepipe Enterprise anti-pattern

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We're continuing our season where we're looking at software architecture, patterns and anti-patterns. In this episode, we're going to look at Stovepipe Enterprise. This is an anti-pattern of just keep patching stuff. Just keep throwing some stuff at it as far as fixes and don't worry about fixing the foundational problems that may be there. You'll see that there are some similarities in our discussion and some of the attitudes with this sort of an architecture that are similar to warm bodies, where it's simply just keep throwing resources at it and it'll be fine or it'll work good enough. Stovepipe Enterprise in general goes back to the concept of a stovepipe, which is actually fairly simple. When you look at wood burning stoves, you've got this pipe because you've got to get all of the crud out, the smoke and the heat and some of that has to come out of it. That's what stovepipe does. It gives it an exit path. The problem with the stovepipe is that that stuff that's traveling through the pipe is highly corrosive and tends to eat up the stovepipe fairly quickly. Historically, stovepipes would just be sort of patched together and start falling apart. Instead of putting a new stovepipe in maybe or something like that, it's just patch it up enough and then just keep on going. You get this Frankenstein's monster or hodgepodge of stuff, of things to keep it going, to keep it functional. In the architecture sense, this is really the stovepipe enterprise is a result of an architectural issue. It is not in itself the architectural issue. The issue being something that is essentially maybe not a one-off, but definitely not a complete solution. Something that's maybe when we talk about Pareto principle and 80-20 rule, we get 80% of the way there and we just sort of move on. What ends up happening is that other 20% is key for stability and even long life of the solution. It either deteriorates over time, such as you find memory leaks and things like that, or it's something that is constantly needing adjustments because maybe we didn't solve for the general case. If the architecture is too specific, then you end up in this situation where every time you get a slight variation, you have to go back, you have to make some adjustments, and then you get this thing that just sort of grows out of hand. The worst case is a story I was told one time about a system that was rather big and this guy also wanted to lock in his job. The way he did it is, and it had to do with pricing. You'd have stuff come through and there would be a price that gets spit out on the other end. Well, over the years, and this is many, many years, there would be bugs or issues would come in or enhancements that said, hey, with this, this needs to be the price. With this, that needs to be the price. What they ended up doing is the person ended up just creating an if statement every time. If this exact entry value comes in, this is what you're going to kick out. Instead of trying to solve for any general cases, it was just every specific case was yet another specific case, which means you're always going to have, or at least for the longest time, you're going to have new changes to make. You're going to have to go in, you're going to have to touch it, you're going to fix it or add to it and then keep on going. It would be the same as if you wanted to add two numbers and instead of just adding the two numbers, using like a plus, you look at the first, the two numbers and you have a case that says, or a long if statement that says, okay, if numbers are one and one, then the answer is two. If numbers are one and two, then the answer is three. If the numbers are two and two, the answer is four and so on and so forth. That's not a very good solution. It's really difficult to maintain and really difficult for the next person to figure out what the heck was going on. When you do something like this, maybe the common phrase that is a warning sign that you may be falling into this pattern or going down this path is when you say, what could go wrong or how bad could it be? We build these architectural pieces, these components, and sometimes we don't really think through what the various permutations are. We sort of focus on the happy path and then instead of allowing for actual uses to cause redesign or refactor our solution. Instead we sort of use like a duct tape approach and then just sort of slam in some code to handle these extra, these special cases. Instead of adjusting the general solution, we take that general solution and we just tack some specific ones on top of it. And that is where you end up running into, that is this anti-pattern. It becomes a never ending stream of work to fix as opposed to, and this is the challenge sometimes, pausing or saying we're not going to be able to respond as quickly because instead we're going to go back and refactor or properly solve this problem. Of course once you have a system that's in production, that can be very difficult or impossible because it may be that people are not, essentially they have to have it. It's not allowed for that system to now be down for some period of time. In which case you're going to have to find a way to refactor the solution and possibly in tandem continue to fight fires until you can put the refactored solution in. This is a perfect example of why technical debt can sometimes be quite an important thing to address. If you keep kicking something down the road and say, well, we'll get to it next time. We'll get to it next time. Sometimes these are issues like with the Sani pattern where there is a cost for doing that. You have the, however you look at it, the per transaction or speed or performance or whatever, whatever metrics you have will show that this thing is getting less useful. That whatever your solution is, is costing more, is taking longer or is maybe not as correct as time goes by. The memory leak issue is probably the best way to see this. That you get to a certain point where maybe initially things are getting a little slower each time, but over time it becomes noticeable. You get to a point where maybe this thing that was coming back in less than a second is now coming back in three seconds or five seconds. The thing is that with a lot of these issues, the Sani pattern itself, thinking about let's go all the way back to the idea of a stovepipe. At some point you've put so much stuff on it. It's not a stovepipe anymore. Eventually, it probably just sort of crumbles under the weight of all of the patching that you've done. It's now broken. It is something that has to be replaced. We see this in software as well. One of the best examples, again, looking at memory leaks is that you get to a certain point where now the memory being consumed is enough that it has to actually go to the hard drive or storage. It's got some sort of caching kind of thing that it does or swapping that it does. Now you're doing transactions with slower memory. Then that continues to grow and eventually you run out of storage space. We've seen this. The good one is when people don't properly design how log files are handled. You'll see a machine will get to the point where there is no drive space available and you're going to have to delete some files. The better thing is to handle those properly and either cycle through them, save them off, whatever so that you don't run into that in the first place. Once you hit it, boom, you have hit a brick wall. You are not moving forward. You can find some, again, some fixes to sort of make it not a brick wall anymore. Like I say, you can, maybe you just turn off, if it's a memory leak, you turn off the program, you restart it. I've seen situations where that's how it works. People have a daily process that all it does is it shuts these things down and starts them back up so that the memory leaks hopefully will not become too much of an issue before you restart it again. If you've got too many files being saved, then it's just, we'll just delete some files off and create some space or add another drive or whatever it is. You're still not fixing the problem in those cases. When you see something hit that brick wall, it should be a big red flag that this is some technical debt that we really need to take a look at because now we don't really know when it's going to occur. We don't know when this thing is going to be, it's going to rear its ugly head and it could be at the worst possible time. So instead of kicking it down the road, we need to put it on our roadmap and say, this is something we definitely need to take care of. Yes, we can limp along, but this limping along hurts us in the long run. And it's not just the instability of the application. It's also the fact that we're pouring resources into this thing on a regular basis to keep it working or to fix it. And those are resources that could be used other places to better use. And this is a, it's one of those things at a certain point where you say, okay, it is better to address the actual issue. For example, if you've got a car that is just getting old or actually any device, but you've got a car that's getting old and now you've got to take it to shop all the time and you're always having to fix things or replace things. There's a certain point where it is cheaper for you to go buy a new car and be making payments on a new car that is reliable than it is to pay for all of the repairs, not to mention the time lost and all that kind of stuff. So we have lots of real world examples that we can point to where we can say, hey, we need to, we need to actually fix this problem. We don't need to patch it. The patching may get us over the hump, may get us through this week or through this one instance, but because we have to patch it, because we have to do this, this fix that is not actually fixing the problem, it's going to cost us in the long run. So we need to raise the awareness of this and get it actually addressed. And again, there's so many different ways we will see this, but another one is where you see a certain component or facet of your solution that is regularly getting bug tickets or defects or something like that attached to it. We're constantly having to put resources back into a component or an area of code and particularly not for enhancements, but because things just are not working right. It's not stable. Actually just about any code, if you go back, if you look at your history of issues with it and you say, yeah, this section of code or this component is not stable, we have issues with it. We've always had issues with it. That right there should be a good indicator that you need to take a look at what is it doing, what's it supposed to do, and maybe it needs to be redesigned, refactored, pulled out, replaced, whatever, in order to actually solve the problem and not just slap band-aids on it. And I think that's where we'll run to the end of this particular anti-pattern, but never fear. We will come back. We'll continue looking at some of these. And we're getting close to the end. So if it's a little depressing to hear all these anti-patterns, that's okay. We're almost to the end, almost through it, and then on to our next topics. But as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. There are two things I want to mention to help you get a little further along in your of the content of Develop-a-Nor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Nor site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week. This is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at develop-a-nor.com if you would like more information. Now go out there and have yourself a great one.