Navigating Technology Sprawl - Streamlining Solutions and Skillsets

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are into yet another episode where we are just walking through each week some of the things that we're running into. Some of it's about building our businesses and some of it's just in our jobs and so the people we interact with, which is what we're going to talk about today. As always, I'm Rob Brodhead. I am one of the founders of Developineur and I'm here speaking with another co-founder, my co-founder, another founder, Michael Melosh. Mike, why don't you introduce yourself? Hey everyone, I'm Michael Melosh. I'm one of the co-founders of Developineur and founder of Envision QA. This episode is actually going to follow up on a couple of things we've talked about in recent weeks and actually something I even wrote, I will call it a blog, a LinkedIn article, post whatever, one of those written content things about technology sprawl is what I've done. I've done a, I actually have done presentations on this recent months and the idea is that we in a business and actually I bet you even personally, if you've been developing probably more than five or 10 years, if you go back, if you've got a personal, which you better have a personal version control repository, whether it's GitHub or Bitbucket or I don't care, SVN, RCS, I can't remember some of the other ones, SourceSafe, all those kinds of stuff. I don't know how far back you go, but you should have your own version control repository that you're keeping up with your code and you have the ability to get to the things that you've done. And probably if you've done this for a while, you will see things done in different languages. You probably have, depending on what you do, you've probably done some websites and HTML and JavaScript. You may have done some Java, maybe you've done some C sharp, maybe you've done some Python or some PHP, you name it. Businesses are just as bad because they've got all these different solutions and then it seems like every six months or a year there's another problem. There's a growth, there's something they're doing. They've got to get another product in or solution in and the next thing you know, they've added another solution. And you end up with all kinds of issues where you've got a whole bunch of overlap, you've got a whole bunch of data you're having to move back and forth. And now you've got something that should be very simple and it's actually incredibly complex. I mean, think about it like if you're just a pet store that all you have are some animals, you've got some supplies, maybe you take online orders. So that should be something you could potentially do like even in one system, you know, or maybe if not one, maybe two, one about fulfillment and inventory and one about sales and stuff like that. But a lot of these companies have got, they've got some spreadsheets they use. They've got stuff that's shoved into some area of Office 365, maybe they've got an access database somewhere and some online somewhere. I mean, they've got HubSpot, but they've also got MailChimp and they've also got yada yada, all those technologies. And we as developers, as technologists, part of being a better developer, I think, is instead of blowing out that technology sprawl and bloat is helping our customers find ways to reduce that, simplify it and make it something that is useful for them. And so we're really talking here about the idea of yourself, and this may seems like a long way to get around to it, but yourself being a master of many things or an expert in one. And this is really today we're talking about like an environment, like a skill set, like are you a generalist database administrator type of person that's really good with SQL and store procedures and things like that? Or are you a specific like I do Oracle or I do Microsoft or I do whatever your tool is and this same thing in languages. Are you just a Java developer? Are you just a .NET developer? Or do you have other skills? And we're going to this can go in so many ways, but this episode, I really want to talk about that sprawl thing about addressing sprawl two ways. One is when you're as you're growing, as you are in an organization and it's moving forward and the other is if you step in an organization that is already sprawled, that already has stuff everywhere and how do you find ways to bring that back in? Now I do want to throw it to you, Michael, first about just the QA side, because I don't think a lot of developers realize the QA cost to sprawl. And so I want you to jump in on that and your thoughts there. Oh, that's loaded. That's loaded. Yeah, QA sprawl is either non-existent, meaning the companies don't have QA at all, or individual teams only do unit testing or testing at the code level, or you have organizations that have multiple teams and everyone's doing their own implementations of QA. No group, there's no company standard. You could have one group using Cypress, one group using Cucumber, one group using Selenium QA. It can be a hot mess because the problem you have in those environments is every single one of those testing tools will similar as far as test defining test stories go. So the testing is totally different. It's even worse if you have third party tools like QTP, Catalon, or any other third party system that you can't, basically if you're writing your test in that, you can't get your test out. You're now locked into that technology. You're locked into that testing framework. So you have to be very careful with the sprawl with QA because you could get into a situation where oops, this company just went out of business. Now my test framework is completely dead. Now what do I do? I got to start over. I got to rebuild everything from scratch, which is very costly to the company. And you may not have the right employees or even knowledge base to even start. People could be gone. It could be a legacy system. So you could be in a heap load of trouble if you're not very careful with defining the technologies that you use, especially with QA. Well, and I want to get actually go a little bit a little different direction with this is test is if you're responsible, you come in and you're responsible for testing for quality for systems that are built across a bunch of different languages so that you've got you got you're coming in and they're saying, hey, we want you to help the quality of our organization. And you look and see that the organization itself has got this sprawl of technology. They've got all these different things hidden in all these different places. Have you run into those and how does that impact testing in the QA effort? Gotcha. OK, different direction, different answer to that question. So with that, and I've walked into a couple of different situations like that. One, any place I go with any technology I bring to a company, especially with QA, I look for three things. Are they using any open source tools that are current? Because if you're using open source, if usually they're community driven, usually they're well-written and well-supported. If you're using third party tools that are proprietary, I try to get away from those as quickly as possible and go to an open source solution. And then three, I tried to define a type of test strategy and test plan for the organization because usually if you're walking into a company with multiple implementations, they do not have a test strategy. They do not have a test plan. They don't even have a QA organization that is covering the different teams. Everyone's kind of off doing their own thing. So typically I try to roll it back. I define the basics. What is it that you need to test? What is it that we need from an architectural level, a user testing level? And then I simplify the whole process. To just what is required from the tester, from the user acceptance testing, because if you go from that direction, if you focus specifically on the end user testing and work your way back, you're probably going to have the best system you need because one, you're going to catch regression testing, smoke testing and user acceptance testing. If you don't have those three, you're in trouble from the beginning. And I think that's where we run into problems with our when we do that sprawl. This is where you're serving your customer or your very well is that you end up focused on the technology. And this is something we'll talk more about when we talk about being a master of many or of one. And you end up stuck in this. It's almost like a blinders on because you're like, OK, this is a technology that I want to use to do this problem, to solve this problem. And it could be very it could be totally viable. It could be the best way to solve that problem. However, you're doing that in a vacuum. So it's almost like think of it as like you're writing a unit of code and you can that unit works great. But if what it takes and what it kicks out are completely irrelevant to the rest of the system, then that unit of code is irrelevant. And sometimes that's what you run into as well as you get you get something built. And yeah, it's fine for its little piece. But and it's it may even serve its specific user story, but it really doesn't fit in the overall story. It would be think about like think of a movie or a TV series you've watched. These are TV series almost always do this where they have like an episode that makes absolutely no sense, where it's like, why did you even put the characters in that situation? It's there is a if you guys think about it, there's like X-Files would do that from time to time where they would have all this stuff and they would suddenly have a standalone episode that really had nothing to do with anything else in the and maybe was never referenced again. It's just whether it's like, yes, it happened and that was it or almost every like animated series where it's just every episode doesn't really have a history to it. It's like, yeah, they've got relationships and stuff, but you don't actually see progression in characters sometimes. It's like if you watch Animaniacs or Bugs Bunny or something like that, Bugs Bunny never talks about like the prior interactions with Elmer Fudd. It's we have those same things with our solutions is that they just sit there and they don't seem to fit because, yeah, they in and of themselves are OK, but it doesn't serve the organization. And that means it's probably serving you or maybe it's serving you in that one customer, that one story. And all of you should have thought about the organization instead of just yourself. It's literally like a selfish development project at that point, as opposed to working to the greater good. Thoughts on that? Exactly, because going back to the QA side of things, because in some organizations, if you have multi-technology stacks or different QA environments, you have different teams of testers that only know one thing. One slight difference. Well, actually, I mean, I guess between developers and testers, we run into the same situations. There are typically when we go out to hire employees to work for us, we're hiring them for what the need is, what the task is that we're looking for. If it's dot net, we're looking for dot net developers. If it's Java, we're looking for Java. If it's testers, we could run into a huge issue here because a lot of testers are really good at one thing. They pick a technology that they like, they know how to use and they hyper focus on it. And that's all they know. They know how to write user stories. They know how to write test cases. They know how to use Cypress, Cucumber. If you try to ask a cucumber tester to write something in Cypress, they're going to be like, I have no idea. And so instead of being able to quickly shift over, you've gone from like what should be maybe an hour. Oh, OK, this look at this to six months. Now, hey, I've got to completely retrain my entire test team on how to use this new application. Whereas if you just stick to people that know how to write tests, understand testing and the same goes with coding. If you have people with computer science backgrounds that actually understand the fundamentals of writing code, typically they can jump into most languages. You should be able to go into C sharp. You should be able to go into Java. You should be able to at least cross transfer most technologies and be able to jump in fairly quickly and do some task or write some code. And I think I don't want to like just blow this all up and not provide a solution. So I think to think about this, when you whether you've grown to this or have walked into this situation is there's actually a lot of benefit from a career point of view, but also for the organization to reduce the sprawl, to take those pieces and roll them into a common solution base, basically. And I think usually you may be in a situation where it's so sprawled out and so diverse that it's almost impossible to pick what is that technology. I've seen a few cases where it's like literally five developers exist in their team and they have five solid applications and five completely different technologies. And so you look at it and you say, okay, what do you guys want to do at that point? Maybe or what is where are you guys most comfortable? You guys being those developers is figure out, is there a reason? Is there some business logic or some cost basis around let's organize around a certain language? Yes, it may be uncomfortable for some of the other developers that maybe aren't it are as comfortable with that language. Maybe that's why there's some of that sprawl, but they will grow and they will be able to do it. And I think that's what you do with that is once you have the that core or that basic stack, is you start looking at identify the things that are not there, that are not a part of that. And then you can start with I always refer to as a sort of a cancerous kind of approach where you can let that thing sit there by itself. But you start finding ways to like through an API or through imports and exports or through something, some sort of integration to suck data or features out of that standalone to the point where eventually you can hopefully just black box it and eventually like cut it off and move it and replace it with a different black box that is now within your technology and then actually even integrate it in. And so you've gone from this thing that is almost impossible to maintain that you always have to call that one consultant that's only available once every six months and all of that. Instead, you've replicated the functionality. You've had them in parallel long enough that you can verify that your new solution works at least as well or maybe better than the one that was there. And now it's in your chosen stack or technology. And so now you've you've learned something about that process. You've probably you've got a good opportunity. So hopefully you've documented that process better. You've gotten out into the organization and talked to whoever the business owners are to make sure they understand what's going on. So now they they know that their process is as part of the fold, that you guys understand it. There's a lot to be gained. And it's from yourself professionally developing it is you've learned something that somebody else wrote and you've actually gone through the process of writing that over in another language, which is always going to it's going to pay some dividends to yourself. So don't think I mean, it could be huge. This could be something that could go on and on and on and on. It could take a long time to roll stuff back in. But that doesn't mean that it's not worth it or that it's just you should just give up. It just means that you should get started today and start working on that instead. Your thoughts? Yeah, that's a good point. One of the things I would also address from a software side, because I know I've been talking a lot about the testing side, is I know I mentioned test strategy and test plan, but even on the software side, from a developer's perspective, if you're walking into these shops and there are different stacks or different technologies going on, one of the questions to ask yourself or even your manager or the company is an organizational level. What is it that the organization wants? Do they want stability across the technology or do they want to be diverse amongst multiple technologies? Because if you're dealing with the latter, they might want you to just go out and kind of pick something and maybe push the element, be bleeding edge. But typically you only find those in startups and larger organizations, more established Fortune 500 companies, you're dealing with larger teams, multiple stacks, but it's more structured. So typically there is some type of technology stack that you're supposed to follow when implementing software. Yeah, that's I guess that is the thing too, is when in doubt, go back to what are the standards or what is it the organization says that they want to do. If it's not being followed, then you point that out and say, hey, this isn't being followed everywhere. What are the, when do you follow it and when do you not? Or that may be a great way to say, hey, let's start rolling stuff back into whatever our standards are that we have to define. We're going to roll you back into our standards of trying to keep this not too long of an episode and allow you to get back to your day to sort of ponder some of this, hopefully to start into cleaning up maybe some of your sprawl. Maybe it's as simple as like writing a couple of unit tests and doing a little bit of documentation so that the stuff that's out there is easier for the next guy or gal. Even if you happen to be that person six months from now looking at code going, who wrote this? And you see your initials and go, oh crap, that's me. Why did I not do a better job of documenting? If you need more documentation about this, you can check us out at developernoir.com or on YouTube with the developer developer or you can even subscribe to us and get all of the latest podcast episodes because we're just going to chug along. We're going to keep going. It's we're basically just going over what is it that you know, what are we learning each week as we're building out our businesses and what are some of the things we're running into as developers? And guess what? That means that'll basically never end. So we've got plenty of opportunities, plenty of content. We'll figure out how to slice and dice these into seasons as we're going forward, as we are sort of approaching what is the typical limit to a season. And so we'll sort of see where we go. As always, you can also you can sign up for the newsletter. It goes out once a month at developernoir.com. You can check us out there. You can send us email and ask us for more information or you can we take requests if there's something you want us to discuss or you've got a question for us to to handle on air as it is on one of our episodes. We'd be happy to do so. But as always, we'll be back next time. And until then, 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 Developer Noir 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.