DOP 285: Navigating the Challenges of Legacy Software in Modern Enterprises
45:49 Share

But we know, as developers ourselves, the journey never ends. There's always maintenance that needs to occur on that software, no matter how well it's written. This is DevOps Paradox, episode number 285. Navigating the challenges of legacy software in modern enterprises. Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor, pretend we know what we're talking about.

Most of the time, we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent.

The truth is out there, and there is no way we are going to find it. P.S. It's Darren reading this text and feeling embarrassed that Victor made me do it. Here are your hosts, Darren Polk and Victor Farsen. Victor, how long has it been since you've worked with a really old piece of enterprise legacy software?

Directly, it's been a long, long time. Now, companies I work with one way or another, they always have some legacy, but I'm fortunately not in it. One of the things I heard in the past is sometimes when you try to bolt new tech onto old tech, it can become challenging, let's say. Maybe not even new tech to old tech, but even mid-tech to old tech. On today's show, we have Neil Millard on. Neil, how are you doing? Hi, I'm good. Thanks for having me.

So we have Nulon. We were talking about what we're going to talk about. And he said that he has a client that's trying to sort of do that ladder, take a mid term old piece of software and trying to bolt it onto and use it with an old, old piece of software. Does that story seem about right? Yeah, that sounds about right. They're trying to get these two pieces of software to work together. And they were both written in very different eras.

And there's not much crossover to work with. Trying to get one to talk to the other can do, but it just feels very clunky and like pushing a boulder uphill. I was always fascinated with those situations and my interpretation of those situations, not necessarily in this specific case, right? Is we have something that we abandoned, hence it's old. Otherwise, if we didn't abandon, we would continue working with it over time and kind of improving it and stuff like that. So it's abandoned, like abandoned house, right? Yeah.

Then many, many years later, we say, we don't want this to be abundant. We want to connect it with something and things like that. To me, that's always fascinating. I always have a bunch of questions like,

Why did you abandon it in the first place? I thought that it's a house that nobody lives in, but actually you do live in it. But you chose not to fix the pipes, right? To fix the electricity and all those things, kind of to remove the holes from the roof. But you actually do live there, right? And you do want to do something with it, yet you choose not to neglect it in a way, right? I think that's possible, especially for me. I know that I have...

In the past, from a tech perspective, it was like, look, this thing has been in here for years, years, and we just can't rip it out because it's the moneymaker or it's a key part to our moneymaking. So we'll just try to keep on, I guess, turning it into Frankenstein's monster. But eventually that's a sad story. Right, Neil? Yeah, absolutely. You can keep bolting things on to the old legacy stuff.

But eventually, I guess we're almost talking about technical debt here, aren't we? Where you've got a piece of code that does something perfectly well, but due to new guys, gals, staff turnover, all those things, it just gets seen as a black box almost. And no one wants to touch it. And yeah, it's fine. You just leave it there or keep doing its thing. But eventually something will happen.

which means you have to open that box. You have to look inside. You have to understand how it actually works in order for it to ultimately be replaced with something that will be a suitable replacement, more up-to-date, be able to keep up with those security fixes and make sure that it all works in unison with the rest of the systems. Because whilst it is that little black box, it's just a big unknown, big risk to the business.

Like you mentioned just now, if it's something that's a moneymaker and it suddenly stops, that's a really, really big commercial risk. But do we really care about commercial risk? Maybe in this room we don't care so much, but then as a contractor, I like my invoices to be paid. So I feel that keeping the business healthy, the golden goose and all that sort of story matters.

It's kind of important, but it can be a hard sell. Certainly if the business needs to invest a lot of money to fix this thing that's not broken yet but could break, that really is a tricky sell to the business. I think that's where the potential problem lies is that I feel that

It's actually much more expensive to fix something after five years or ten years of not touching it than actually keeping it up to date. Like you mentioned security risks, right? Any library that is not updated in a month or less...

is a security risk, right? Because new vulnerabilities are found, right? And I assume that when we have a black box that we're talking about libraries and whatever is in it that hasn't been probably changed for years, either that company or entity is unaware of how security works or they're kind of ignoring security until something happens, right? Yeah. Usually, if it's quiet, nobody notices it.

Like most things that get your attention, they have to be loud or flashy and then you'll notice that they're there. Indeed, in the terms of security, then yeah, if something's quiet and nothing's been touched for ages, I mean, how many bugs have we heard about this year or in the last 12 months?

where the actual vulnerability has been there for 10, 15, even 20 years, and it's only just been found. Yeah, and then you're in a situation that you probably cannot even update that library with a fix for that vulnerability because you're 10 years behind. There is no way it's going to be backwards compatible. There is no way that update will not break something, right?

Yeah, I mean, I've had projects where I've not built it for maybe two months and all of a sudden all the dependencies are out of date and that thing just won't build. And so, yeah, if you're talking years rather than weeks, then you are in a situation where to fix that one thing, you pretty much have to rebuild the whole house, to use your analogy. So when does it become more optimal to rewrite than to renew something that was neglected? Gee, that's a hard question to answer.

With my consultant hat on, I can say it depends. I guess, I mean, we've already said that the cost of running it is usually less, but the cost of replacing it is going to be quite high. Can it come back to business value again? How critical is it? It's a bit like the argument of should we automate something? There's processes for everything, but if you're only going to touch that process once a year, it's not worth spending two days automating that process if you're only going to run it once a year.

So to replace something entirely is quite a big undertaking. Unless, of course, you can get help from an off-the-shelf package or there's a lot of libraries that can reduce that development time. So it really, really does depend on the specifics around the project. Because that's then a tough situation, right? Rewriting, is it not a financially viable option? Keeping it as it is,

is not the option because requirements, let's say that that's 10 years old. 10 years ago, we had requirement to have 100 concurrent requests. Now we have a requirement to have 10,000 concurrent requests. There is no fix that we can apply to make that something behave. So kind of basically it's a limbo, right? It doesn't do what it needs to do. It's not secure. Rewriting is not an option. Tweaking it is not an option. What is left for companies to do then? I guess...

try and make that component obsolete. That would be kind of rewriting, right? Yeah, it's kind of rewriting, but it's rewriting with a means to an end. So I can think of another project that we had. There's this little library and it takes in a bunch of YAML files

And it spews out more YAML because, of course, it does. The main purpose of it is that the YAML that comes in is all encrypted and the YAML that comes out is all decrypted and usable by the applications. And this library was very much treated as a black box. And so as they were, the team, building more functionality into their main product that relied on this library,

different aspects of that library just got pulled out and replaced at a time. So it was a rewrite, but it wasn't really a rewrite as a project. It was as we touch the code base that's using that component, we just move stuff over and rewrite it over a long period of time. Almost disappears into business as usual costs.

That code you said, that's the code that encrypts the crypts stuff, right? Yeah. That's also curious, right? I don't know whether this is the case, but in general, right? Company wrote some code that does something and it wrote that code that does something because there was no project that accomplishes the same function, right?

But then in the meantime, like right now we have dozens of tools that like external secrets operator, SOPs, sealed secrets and so on and so forth, right? Dozens of tools that do those things. How do companies, when, even if, should they switch and say, okay, actually this doesn't make sense for me to have it as my own code? So it would make sense to switch if you're updating the upstream, the main program.

That's the opportunity when you can reassess it. Let's imagine that-- so this piece of code, it creates configurations. And so if you're changing the way that you're deploying code and therefore pulling this configuration in, that's a reasonable time to then evaluate whether you want to use this legacy piece of code or you want to upgrade it to another product entirely because you're already

in the process that uses it. Yeah, you can address that dependency chain at that point. I want to play a little game here. Neil, I am putting out an RFP as a company for you to bid on as a contractor. And here's the high level thing, just the high level through line. I need someone to come in because I don't want to task my full-time staff with this. I want someone to come in and work on my code

and eliminate all security issues that exist today and that will ever exist again in the future. Would you take that contract? No. I was okay with the first requirement, but as soon as you said, and all in the future, we can't possibly know what's in the future. So I would either get them to remove that requirement or to say, yeah, that's

too much of a risk for me to be able to give you a promise. I cannot promise that future stuff won't break it. Okay. So I'm going to, I'm going to keep digging here just a little bit. So what you're telling me is you're fine with the current stuff. Yep. I can buy that, but it's our business requirement to never have any, uh,

issues, any security issues with any software that we have, whether it's software that we've written or any software that we acquire or use from open source. And you're telling me you cannot prevent us or protect us from any security issues in the future from any software anywhere. Not in one solution. It would have to be an ongoing process. No, I just need it done in the next two months. Sure. Now I can deliver you something that's as secure as it can be now.

But I don't think my insurance company would even cover me for this might be insecure next week. We'll stop role playing there. You fought business with business by saying my insurance company would not cover this. Yeah. You have written a book on consulting. It's more UK based. There are some global things, but this insurance thing is a big deal if you've done contracting in the past, which I did for about 10 years. Carrying E&O...

Emissions and what is it? Not emissions. Errors and omissions. I've put the two words together. Errors and omissions. And there's probably other UK specific insurances as well. This is a big deal. If you think if you're just going to start doing some contract work, if you're working with a business and not just your friend, you might run into some problems later on.

Yeah, for sure. Because stuff can go wrong. Stuff always goes wrong. It's just a matter of time. I guess it happens anyway, but if a business suffers a loss as a result of something you've done, they want to be able to point the finger strongly at you and recover those losses. And that's on top of putting whatever has gone wrong and putting it right. We won't go down much more of that rabbit trail there, but the

When you were talking about security stuff earlier, I had to play out the other issues now and any in the future. Because I've seen requests recently, just looking through forums, for people asking for that. It's like, hey, we've had too many security issues in our company. We need to make sure that our software will never have a security issue ever again in the future. And I looked at it and rolled my eyes and then just sadly laughed.

Yeah. The only way you can avoid not having those issues is by not having the software. Yeah. But we have to have software, right? Yeah. That's not really a good answer. But it's the correct answer, unfortunately. I want to go back to one of the things you said earlier, staff turnover. Yeah. You come in as a contractor a lot, and I'm saying contractor and not consultant. I'm saying that specifically because there's a big difference. Yeah. How do you classify the difference between contractor and consultant? And then we'll come back to turnover in a minute.

So a consultant can be a permanent member of staff that works for a company. That company could acquire the use of a consultant by engaging with a third party consultancy, or they could do the same thing with a similar to my business, a consultant that acts as their own business.

A consultant is the service that's being provided, whereas contractor is the way by which it's provided. The other way I've used it in the past is body shop. Yeah. Just back up the bus, dump a bunch of bodies off the bus, do the work. They can stay there for, if you're in the US, 18 months, and then they have to leave because of Microsoft. Thank you, Microsoft. And the cycle starts all over again.

which leads us back to staff turnover. Now let's type back into what we were talking about at the very beginning. You're currently working on a project to where we're integrating a midterm technology with an old term technology. In fact, I'm going to make it a little bit harder here or a little more clarifying here. Git is the midterm technology and the old term technology. I'm not going to name, but let's just say it's an enterprise piece of analytics software.

That way that stays very broad because there's many of those. What you were saying offline was there's some issues between making those two work nicely. Now, with that older piece of analytics software being there for probably decades, I imagine there has been quite a bit of staff turnover. And I'm assuming that this place that you're contracting at is a large enterprise, correct? Correct. So what's the chances of, unless there's certain places to where staff turnover is smaller,

just because benefits are great, but hey, who knows? What has the staff turnover been like on something that's in this specific project, do you think? Because you haven't been there forever, but what do you think it's been like? I would imagine the turnover is probably based on, again, contract renewal. So most of the staff there are consultants in one way, shape, or form.

and they don't work directly for the client. So as the client tries to reshuffle themselves, maybe get better terms on the contracts, they will lose or replace consultants with other consultants. So I can imagine they probably have fresh faces because of different external companies that they're engaging with, probably every, like you said, 18 months, 24 months, something like that.

The silliness of that to me, we're concerned about business continuity and you're turning over your people working on it. It seems insane to me. Now, let me ask this question. That's sort of, I want to, I want to get somebody on tape saying this besides just me in this area that you're working in, in this project, how many full-time employees are in that project?

And how many contractors? And you do a percentage. What do you think that percentage is? Breakdown of full-time employees versus contractors? On this project, I don't know exactly because it's difficult to see where everyone is engaging from. But if I had to guess, I would say maybe 20% full-time are working directly for the customer, as in they are staff. And 80% are external to that company.

See, that's something very special I feel with software compared to other areas is that I don't think that there are any other areas of business where a company would at the same time say this is business critical and I'm externalizing it. Usually, like let's say if it's a bank, right? And then people, financial people, they're internal because that's business critical and then we externalize.

cleaning services, right? Because that's not business critical. But in software, it's very special that it is at the same time business critical, yet it is treated as if it's not in a way, right? Is that not down to how it's funded though? I mean, we can talk about capital expenditure versus operational expenditure and the development of software is very much seen as a project, a one-off thing that's created

But we know, as developers ourselves, the journey never ends. There's always maintenance that needs to occur on that software, no matter how well it's written. So going back and using what you were saying there, that development part is usually capexed.

But that ongoing maintenance is typically, typically op-axed. Yeah, that's right. I've worked on contracts before to where we're in cap-axing the maintenance, which was a pain in the butt because there were certain parts that, okay, well, we've got to classify this line as a cap-ax and classify this line item as op-ax. And I was like, okay, you guys figure that out in the back end and just give me the correct line item that I have to put my timesheet against.

This is the other reason why I don't like contracting anymore. I got tired of timesheets. Yeah. Timesheets are a pain, but I don't know a better way of recording it. Yeah, there isn't. And especially like the scenario I was just talking about to where you get, there was one time I did a timesheet in a month and I had close to 70 or 80 line items because the tickets I'd pulled that month were 70 to 80 tickets, 60, 70, 80, whatever the number was I said.

And every one of them, I had to keep it. And I also had to keep my time down to a tenth of an hour. Every six minutes, I had to log my time. What's that like in the UK? Is it that insane? I can imagine that some might operate like that. But fortunately, from my experience, it's different. I suppose the minimum quarter a day, two hours, would be the smallest increment that I've had to deal with, certainly in the last year.

15 or so years. And that's largely because we structure the contract in such a way that it has a statement of works. I'm responsible for delivering this, this and this. And it doesn't go much into what you might call line items. It's like, here's the contract between me and the customer and

And I'm responsible for delivering these things. And it's kept at quite a broad level as far as the contract's concerned. So then it just comes down to a case of the customer being happy that I have been there. I've been present for a certain calendar day, half day. And that's the timesheet level that I currently record at. However,

There is the case that whilst a customer might be delivering the same service, let's say I'm looking at delivery pipelines for automating the build and deploy of software. That's pretty vague and broad, but the customer may want to allocate that as an expense to multiple projects so that you might end up with a system on their internal timesheet that they say, okay, you spent

two hours on this project and six hours on this project. And that can be all over the place. And certainly when I worked for this customer on this particular section last time, which was some like eight years ago, it was a little bit more like that. But these days, the timesheets requirements have reduced drastically, which is great for me because it makes things simpler.

Let's go back to the staff turnover because we're sort of jumping in and out and I'm the one that's causing the problem. The 80-20 rule pops up everywhere in life. 20% full-time, 80% contractors that are going to be slotted in and out based on who either gave procurement the best steak dinner or the best vacation or the best golf game. And going to what Victor said, in software, we throw the cheapest people in

And I'm making a gross generalization here. We throw the cheapest people at the most critical problems in our business. And we expect them to be on site and sitting at a desk and following all of our rules. So you get to be a full-time employee without being a full-time employee of the person you're working for or contracting for. No wonder there's so much staff turnover because forgetting the legal part of it, it's like, boy, that just seems like a miserable thing. Like when I was contracting, I,

I was a one-man shop. So it was sort of a hired gun, if you will. And that was great for me because I was able to pick and choose the jobs I wanted to do. I was very fortunate with the number of clients I had, even though we had these weird down to every six minutes thing. But okay, I got over that. How can we convince enterprises that if they really want to grow, again, CapEx, OpEx, we've talked about that. If they really want to grow, maybe they need to bring and flip it the other direction. Maybe it should be

80-20 FTE versus contractor? I think they have to treat software completely differently. So we are talking about the CapEx and the OpEx. As long as they see software development as a short-term thing, they're not going to have that long-term thinking where a lot of businesses want full-time employees for because they see them as being around for a long time.

I think the disjoint here is where we know that software deployment takes a long time. Even when it's finished, it's then being tweaked. And one of the older projects I was on, I think all in all, it lasted about nine years before they then decided it was, if you like, stable. The development was stabilized to such a point where it was now really, we just need to look after it.

security updates, patches, but no new functionality or anything like that. Even then, they were just going from two-year cycles to two-year cycles with no real long-term view on it. So why would they hire a full-time person if they don't have a long-term view on it? But I'm assuming those people were the ones actually doing the BRDs, business requirement documents, right? I mean, somebody had to have had a long-term picture of this.

Usually, you know, those changes happen when competition emerges. We see that in the car industry right now. Volkswagen is forced to change drastically how they operate because of BYD or whatever it's called, the Chinese company, Carmaker and Tesla and others, right? Usually, there is a big difference between, hey, what I'm saying and what I'm doing and...

what I'm doing because I'm forced to do it differently in a way, right? Similar thing happened, for example, in banking industry in some parts of the world after few banks said, hey, this matters. We're taking it seriously, right? In a very different way. It still raises the question of how seriously does the business think that core functionality of the software is to their business core? Yeah, more going into direction of

One thing is what we were thinking until today, but now we're going out of business because those new companies are coming out of the blue. It's completely destroying our business, right? Which happens once in a decade in one industry, right? Now we're experiencing that with car industry. Before that, we were experiencing with others. Maybe that's what's needed, right? To have some real disruption of a whole industry, right?

for companies to realize that they maybe should do something different or go bankrupt. Yeah, maybe. Because a lot of startups, if I can generalize, tend to be software companies. And their core product is the software, which is, in old school terms, a process that a computer does, rather than people doing it. So in the UK, the disruptor banks...

Okay, they're in the banking sector, but they are software startups. And I think that's the point you're making. Exactly. And if you know, when you reach the point where you cannot buy startups anymore, you cannot buy them off, you cannot buy competition anymore. Competition grew too big to be bought. But the question is then, if that's the moment when you start reacting, is it too late? Maybe, because by the time you've noticed something...

It's big enough to notice. And so they've already got that momentum. As we can see, larger organizations do take a long time. Like a large ship, they take a good turning circle to change direction. And so the smaller startups are going to be more nimble and can outpace them, even if the larger company is trying to change direction.

So let's see if we can take the story back to where we started. We've talked about all the human issues around this. Let's see if we can land it with the technical issues. We've got a midterm technology that I'm saying is Git, which it is. We've got super old software from an analytics standpoint. We're trying to make these two talk nicely together. Now, as the business owner, I would say, hey, contractor, because...

This is important to me. It's really business critical, but I don't have anybody on staff that knows Git because we're that far behind. We're still using CVS and RCS. How would you approach coming in and trying to tackle that problem, which is what you're doing now? I guess the main reasons why these tools don't work well together is because the legacy software doesn't expect to have something else

help manage it. It is written like a monolith application. You know, everything is under its control and it doesn't want to give any part of that up. So where we've got something like Git that wants to be friends with it and help take a little bit of the workload off, you know, there's no real way for it to fit in and it will still be external.

And I suppose the only way that I can help with this is just to make the external system play as nicely with the old system. Because fortunately, it does have a command line interface, which means we can write batch scripts in order to deal with it.

And those batch scripts can also interface with other systems using curl requests or APIs and stuff like that. And so we can develop some middleware just to act as the interface between those two. But it's doing a lot of heavy work that would be easier if the legacy monolith application was changed in order to let it in, to have that little door that it can work with and cooperate with.

which may be possible. The vendor of this software is releasing updates because they're a software vendor, therefore they have to keep the security updates in there. But then they're also starting to embrace the newer technologies, which means a new version entirely of that software. Let's bring in the term microservices. They've caught that microservices bug and as a

monolith type of software they've learned or rather they've been told that you know microservices make everything much better which is true in some respects but i don't think it's like any ideas it can be abused and so they'll replace that legacy software with something a little bit newer maybe with a mic microsoft si micro services architector and they'll

That will then make that integration easier because those microservices need to be able to talk amongst themselves, which gives external software like Git and like APIs more interface points in order to work with it. I'm being silent as much as I can on the microservices thing. I think it's funny sort of how you stated it. It's like enterprise vendor looking at the new things like Git and microservices. Yeah.

That were 10 years plus old. The other thing that I thought was interesting too is you're talking about the nine years. We now consider something stable after nine years. And I'm thinking, okay, Kubernetes just celebrated its 10th birthday. It's just now stable. So that's in alignment, but boy, it's still moving forward at pretty great pace. I wonder if that 10 year mark is actually an important number to look at.

It feels like it. The fact that you've drawn those conclusions just from the three examples we've spoken about, it certainly feels like that could be a thing. But what does it mean? Does it mean it's going to be replaced by something new and shinier? Or does it mean that product, once it hits a 10-year mark, slowly dies a death until it is eventually replaced? I think that's one of the big problems with companies are

or mistakes they're making, right? Yeah, of course, Kubernetes will be replaced with somebody else. I'm using it as an example. Of course it will. Everything eventually gets replaced, right? But then if you think in terms like, hey, will this be replaced with something else, then you never do anything in a way, right? Hey, it will. Of course it will. Everything does.

Which is why we come back to our original question that software development is a capex because eventually it will be replaced by some other software. I mean, that probably applies. Maybe timeframes are different. That applies to everything, right? We are not driving the cars that we were driving 50 years ago. Buildings are constructed in a different way today than 50 years ago and so on and so forth, right? But that's generally not a problem anymore.

when you have a decently paced adoption, right? So whomever adopted Kubernetes five years ago is still having nobody knows how much ahead of it, right? Before it gets replaced. Now, if there is a company, and I hope that there isn't a company anymore who is still thinking whether this is a thing or not, Kubernetes, then yes, of course, by the time they finish thinking, it will be replaced.

But that's not the fault of Kubernetes or any other technology. That's the fault of companies kind of moving just too slow, right? If 10 years is not enough for a company to adopt something, then nothing is in a way, right? Yeah, because the other figure that pops up a lot in business is the 20-year mark.

whereby, okay, we're saying software takes 10 years to become stable, but then it seems that 20 years is how long it takes for a startup to become stable. Companies like Facebook or Amazon were trading for 15 to 20 years before they then became what you might call globally recognized. And presumably they've got software products on the inside, internal development,

that are younger than that. So there must be some sort of relationship between the two, or is that just a marketing thing that gives rise to that 20 years? I'm not sure about the 20 years, right? Because Facebook took its example, right? If anything, accelerating, not slowing down. Companies like Facebook, they probably did within first year more than a traditional company does in 10 years.

What a traditional company 20-year mark might be, that's probably closer to a year mark in more agile companies. When I say agile, I mean in the literal meaning of the word, right? Take a look at, for example, software in cars, right? Volkswagen has been building software since the 80s. So we're not even talking about 10 or 20 years, Mark. We're talking about 40, 50 years. And it's still not even close yet.

to what Tesla or Rivian did in a couple of years. Oh, see, that's where I think you're wrong. Well, wrong may be too strong. Rivian and Tesla wasn't a couple of years. It appears to have been a couple of years. True. But they're probably, I don't have their birth dates, but they're probably in the 15 to 20 year range as well. True. But if you look at, if you look at, let's say, uh,

Compared to a Volkswagen, yes. Not only that, but I'm not necessarily saying Tesla or Tesla today, right? I'm talking about take a look at what they did the first five years. I'll buy that. But anyway, yes. The other thing we're talking 10 and 20, let's stick with 20 for a second. Let's say you went to work for a company when you were 30. Now it's been 20 and now you're 50. Just that basic math.

Of those 20 years. When we say 20 years in software, it's like, okay, 20 years in software. But when you put it on your human body and saying, I started with this when I was 30 and now I'm 50 and I'm still doing the same thing. That becomes very demoralizing sometimes, I would guess. Unless maybe you're working at Tesla or you're working in what feels like something always new and hot and ever-changing versus probably...

financial services or insurance to where it just never really changes. Yeah. I mean, I'd argue it doesn't change. You know, even if you've been doing software for 20 years, you've not been doing the same software for 20 years. You've been doing different software for 20 years. You would hope. Yeah. Well, 20 years ago, we didn't have Golang. And it was a wonderful world without it. In fact, Python, I think it's only about 25 years old.

Or am I way off there? Because I'm getting old myself and therefore things seem more recent than they really are. Well, that's what I'm saying is we mentioned, oh, yeah, this thing's 20 years old. But then I'm thinking, okay, well, I started working with it 20 years ago. It's like, oh, back when my left knee didn't hurt. That's when I started working with it. So we've gone all over the place here today. We've talked about trying to fit a square peg into a round hole where the square peg is actually bigger than the round hole.

Hint, hint. There's always a way to solve that problem. Just make the square smaller than the hole. It'll go right through. Talked about contracting versus consulting. Neil, is there anything else that we should think about? I was like, let me ask you this point. If somebody was thinking, you know what? I'm fed up with this whole full-time employment thing.

I see these contractors going back to the 80-20 rule. I see all these contractors coming in. They come in at 9 o'clock. They leave at 5 o'clock. I show up at 6 a.m. I don't go home until 9 p.m. They're getting paid for every hour they're here. I am salaried. I don't get any extra time, and I'm expected to be here on the weekends for free. What would you tell full-time people thinking about going contracting?

Is it really that great? Well, I mean, that's a very visceral picture you painted and exactly one of the reasons why a lot of people make that leap. I agree from that perspective, it is that great. It's not without its challenges. As a contractor in the UK or elsewhere, we spoke about insurance. You need to make sure that something you've done last year isn't going to bite you this year.

There are reporting and compliance issues that you have to deal with because you are a business. And so part of running any business means you have to have some level of reporting, be it around compliance of insurances being in place. You know, if somebody trips up and falls in your presence, then perhaps that's your fault.

as well as the insurances for the work you've done. And then there's the money side of things. There's the compliance with the tax authorities to make sure that you're paying the correct level of tax and reporting what your income is and what your expenditures are so that you can work out what that correct level of tax is. And then touching on cash flow, there's the making sure you get paid. So sure, as a contractor, you might go on site, do your thing,

I'm sending invoice at the end of the month. And then sometimes the good customers, they'll pay that invoice at the end of the month. So if you've come in on the first of the month, you don't invoice that until the end and then they don't pay it until the month after that. So that's 60 days after you've done the work before you even get paid for that, which means you have to be really good with your personal cashflow as well. It's certainly when you get started, then there's getting the contracts in the first place. You know, where do you find them?

It's a bit like finding a job, but the contract market is a little bit different. The contract lengths are much shorter. So there might be the period where you'll have a six month contract and then you don't find any work for two months. Great. You get some free time to yourself, maybe work on that side project, maybe do some training, but then you start looking at your cash flow and that starts to dry up a bit, which can be a little bit stressful.

So there are good points. Yeah, you can choose what projects you work on when the market is abundant. Sometimes you work on less desirable products and projects when the market's not quite so abundant like it was last year. So, yes, there's there's always a risk. There's always bad things and there's always good things. But being prepared for the bad things makes them easier to deal with.

And as long as you deal with them, it's pretty straightforward. And all that information he was talking about on contracting can be found in Neil's book, Confident Contractor, which can be found on Amazon. In fact, I looked at it the other day. In the US, it was 99 cents. Now, it is very UK-based. So for anybody reading it outside of the UK, you might say, okay, this doesn't make sense. Just try to replace the big blocks and you'll get it. But

Just because you have to work on the weekend for free as an employee, that may still be better than trying to run your own company. So we'll have all of Neil's contact information down in the episode description. Neil, thanks for being with us today. Thank you. It's been fun. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and a link to the Slack workspace are at devopsparadox.com slash contact.

If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at DevOpsParadox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.