Broadening Your Horizons, or Why Broadcom Won’t Get VMware

You might have missed the news over the weekend that Broadcom is in talks to buy VMware. As of right now this news is still developing so there’s no way of knowing exactly what’s going to happen. But I’m going to throw my hat into the ring anyway. VMware is what Broadcom really wants and they’re not going to get it.

Let’s break some of this down.

Broad Street

Broadcom isn’t just one of the largest chip manufactures on the planet. Sure, they make networking hardware that goes into many of the products you buy. Yes, they do make components for mobile devices and access points and a whole host of other things, including the former Brocade fibre channel assets. So they make a lot of chips.

However, starting back in November 2018, Broadcom has been focused on software acquisitions. They purchased CA Technologies for $19 billion. They bought Symantec the next year for $10 billion. They’re trying to assemble a software arm to work along with their hardware aspirations. Seems kind of odd, doesn’t it?

Ask IBM how it feels to be the dominant player in mainframes. Or any other dominant player in a very empty market. It’s lonely and boring. And boring is the exact opposite of what investors want today. Mainframes and legacy computing may be the only thing keeping IBM running right now. And given that Broadcom’s proposed purchase of Qualcomm was blocked a few years ago you can see that Broadcom is likely at the limit of what they’re going to be able to do with chipsets.

Given the explosion of devices out there you’d think that a chip manufacturer would want to double and triple down on development, right? Especially given the ongoing chip shortage. However, you can only iterate on those chips so many times. There’s only so much you can squeeze before you run out of juice. Ask Intel and AMD. Or, better yet, see how they’ve acquired companies to diversify into things like FPGAs and ARM-based DPUs. They realize that CPUs alone aren’t going to drive growth. There have to be product lines that will keep the investor cash flowing in. And that doesn’t come from slow and steady business.

Exciting and New

VMware represents a huge potential business arena for Broadcom. They get to jump into the data center with both feet and drive hybrid cloud deployments. They can be a leader in the on-prem software market overnight with this purchase. Cloud migrations take time. Software needs to be refactored. And that means running it in your data center for a while until you can make it work in the cloud. You could even have software that is never migrated for technical or policy-based reasons.

However, that very issue is going to cause problems for VMware and Broadcom. Is there a growth market in the data center in an enterprise? Do you see companies adding new applications and resources to their existing enterprise data centers? Or do you see them migrating to the cloud first? Do you imagine given the choice between building more compute cluster in the existing hybrid data center or developing for the cloud the first time that companies are going to choose the former?

To me, the quandary of VMware isn’t that different from the one faced by IBM. Yes, you can develop new applications to run on mainframes or on-prem data centers. But you can also not do that too. Which means you have to persuade people to use your technology. Maybe it’s for ease-of-management for existing operations teams. Could be an existing relationship that allows you to execute faster. But no matter what choice you make you’re incurring some form of technical debt when you choose to use existing technology to do something that could also be accomplished with new ideas.

Know who else hates the idea of technical debt and slow steady growth? That’s right, investors. They want flashy year-over-year numbers every quarter to prove they’re right. They want to see that stock price climb so they can eventually sell it and invest in some other growth market. Gone are the days when people were proud to own a bit of company and see it prosper over time. Instead, investors have a vision that lasts about 90 days and is entirely focused on the bottom line. If you aren’t delivering growth you don’t have value. It’s not even about making money any more. You have to make more all the time.

The Broad Elephant

The two biggest shareholders of VMware would love to see it purchased for a ton of money. Given the current valuation north of $40 billion, Dell and Silver Lake would profit handsomely from a huge acquisition. That could be used to pay down even more debt and expand the market for Dell solutions. So they’re going to back it if the numbers look good.

The other side of this equation is the rest of the market that thinks Broadcom’s acquisition is a terrible idea. Twitter is filled with analysts and industry experts talking about how terrible this would be for VMware customers. Given that Symantec and CA haven’t really been making news recently would tend to lend credence to that assessment.

The elephant in the room is what happens when customers don’t want VMware to sell? Sure, if VMware is allowed to operate as an independent entity like it was during the EMC Federation days things are good. They’ll continue to offer support and make happy customers. However, there is always the chance something will change down the road and force the status quo to change. And that’s the thing no one wants to talk about. Does VMware reject a very good offer in favor of autonomy? They just got out from under the relationship with Dell Technologies that was odd to say the least. Do they really want to get snapped up right away?


Tom’s Take

My read on this is simple but likely too simple. Broadcom is going to make a big offer based on stock price so they can leverage equity. The market has already responded favorably to the rumors. Dell and Silver Lake will back the offer because they like the cash to change their leverage situation. Ultimately, regulators will step in and decide the deal. I’m betting the regulators will say “no” like they did with Qualcomm. When the numbers are this big there are lots of eyeballs on the deal.

Ultimately Broadcom may want VMware and the biggest partners may be on board with it. But I think we’re going to see it fall apart because the approvals will either take too long and the stock price will fall enough to make it no longer worth it or the regulators will just veto the deal outright. Either way we’re going to be analyzing this for months to come.

Quality To Be Named Later

programming

First off, go watch this excellent video from Ken Duda of Arista at Networking Field Day 28. It’s the second time he’s knocked it out of the park when it comes to talking about code quality:

One of the things that Ken brings up in this video that I thought would be good to cover in a bit more depth is the idea of what happens to the culture of your organization, specifically code quality, when you acquire a new company. Every team goes through stages of development from formation through disagreement and finally to success and performance. One of the factors that can cause a high-performing team to regress back to a state of challenges is adding new team members to the group.

Let’s apply this lesson to your existing code infrastructure. Let’s say you’ve spent a lot of time building the best organization that has figured out and your dev teams are running like a well-oiled machine. You’re pushing out updates left and right and your users are happy. Then, you buy a company to get a new feature or add some new blood to the team. What happens when that new team comes on-board? Are they going to integrate into what you’ve been doing all this time? Do they have their own method for doing development? Are they even using the same tools that you have used? How much upheaval are you in for?

Buying Your Way To Consistency

Over a decade ago, United Airlines bought Continental Airlines. Two years later, the companies finally merged their ticketing systems. Well, merged might be a bit of a stretch. United effectively moved all their reservations to the Continental system and named the whole thing United. There are always challenges with these kinds of integrations but one might think that part of the reason for the acquisition was to move to a more modern reservation system.

United’s system was called Apollo and built in the 1970s. How could they move to a more modern system? Was the reason for the huge purchase of another airline directly related to their desire to adopt a newer, more flexible reservation system? There have certainly been suggestions of that for a number of years. But, more importantly, they also saw the challenges faced by one of their Star Alliance partner US Airways in 2007 when they tried a different approach to merging booking systems. The two radically different code bases clashed and created issues. And that’s for something as simple as an airline reservation system!

In the modern day we have much more control over the way that code is developed. We know the process behind what we do and what we write. When we build something we control it the entire way. However, that is true of everyone that writes code. And even with a large number of “best practices” out there no two developers are going to approach the problem the same way unless they work for the same company. So when you bring someone on board to your team through acquisition you’re also bringing in their processes, procedures, and habits. You have to own what they do because now their development quirks are part of your culture.

Bracing For the Impact

There’s a lot of due diligence that happens when companies are purchased. There’s an army of accountants that pore over the books and find all the potential issues. I’d argue that any successful merger in today’s world also needs to include a complete and thorough code review as well. You need to know how their culture is going to integrate into what you’re doing. Never mind the intellectual property issues. How do they name variables? Do they call the same memory allocation routines? Do they use floats instead of integers because that’s how they were taught? What development tools do they use and can those tools adapt to your workflow?

It may sound like I’m being a bit pedantic when I talk about variable naming being a potential issue but when it comes to code that is not the case. You’re going to have to train someone in procedure and you need to know who that is before they start committing code to your codebase. Those little differences are going to create bugs. Those bugs are going to creep into what you’re working on and create even more problems. Pretty soon something as simple as trying to translate from one IDE to another is going to create a code quality problem. That means your team is going to spend hours solving an issue that could have been addressed up front by figuring out how things were done in two different places. If you think that’s crazy, remember NASA lost a satellite over a unit conversion problem.


Tom’s Take

You may never find yourself in the shoes of someone like Ken Duda. He’s committed to quality software and also in charge of trying to integrate acquisitions with his existing culture. However, you can contribute to a better software culture by paying attention to how things are done. If you do things a certain way you need to document everything. You need to ensure that if someone new comes into the team that they can understand your processes quickly. That way they don’t spend needless hours troubleshooting problems that were lost in translation at the start of the process. Do the hard work up front so you aren’t calling people names later.

Friday Thoughts on the Full Stack

It’s been a great week at Networking Field Day 28 this week with some great presentations and even better discussions outside of the room. We recorded a couple of great podcasts around some fun topics, including the Full Stack Engineer.

Some random thoughts about that here before we publish the episode of the On-Premise IT Roundtable in the coming weeks:

  • Why do you need a full stack person in IT? Isn’t the point to have people that are specialized?
  • Why does no one tell the developers they need to get IT skills? Why is it more important for the infrastructure team to learn how to code?
  • We see full stack doctors, which are general practitioners. Why are there no full stack lawyers or full stack accountants?
  • If the point of having a full stack understanding is about growing non-tech skills why not just say that instead?
  • There’s value in having someone that knows a little bit about everything but not too much. But that value is in having them in a supervisor role instead of an operations or engineering role. Do you want the full stack doctor doing brain surgery? or do you want him to refer you to a brain surgeon?

Tom’s Take

Note that I don’t have all the answers and there are people that are a lot smarter than me out there that have talked a lot about the full stack engineering issue. My biggest fear is that this is going to become another buzzword just like 10x engineer that carries a lot of stigma about being less than useful while being a know-it-all. When the episode of the podcast comes out perhaps it will generate some good discussion on how we should be handling it.

Ease of Use or Ease of Repair

HammerAndSaw

Have you tried to repair a mobile device recently? Like an iPad or an MacBook? The odds are good you’ve never even tried to take one apart, let alone put in replacement parts. Devices like these are notorious to try and repair because they aren’t designed to be fixed by a normal person.

I’ve recently wondered why it’s so hard to repair things like this. I can recall opening up my old Tandy Sensation computer to add a Sound Blaster card and some more RAM back in the 90s but there’s no way I could do that today, even if the devices were designed to allow that to happen. In my thinking, I realized why that might be.

Build to Rebuild

When you look at the way that car engine bays were designed in the 80s and 90s you might be surprised to see lots of wasted space. There’s room to practically crawl in beside the engine and take a nap. Why is that? Why waste all that space? Well, if you’re a mechanic that wants to get up close and personal with some part of the engine you want all the space you can find. You’d rather waste a little space and not have busted knuckles.

A modern engine isn’t designed to be repaired by amateurs. The engine may be sideways or have replaceable parts put in places that aren’t easily accessed without specialized equipment. The idea is that professionals would have everything they need to remove the engine if necessary. Moreover, by making it harder for amateurs to try and fix the issues you’re are preventing them from doing something potentially problematic that you’ll have to fix later.

The same kind of thing applies to computing equipment. Whereas before you could open the case of a computer and try to fix the issues inside with a reasonable level of IT or electrical engineering knowledge you now find yourself faced with a compact device that needs specialized tools to open and even more specialized knowledge to fix. The average electrical engineer is going to have a hard time understanding the modern system-on-a-chip (SoC) designs when you disassemble your phone.

Usability Over Uniqueness

The question of usability is always going to come into play when you talk about devices. The original IBM PC was a usable design for the time it was built compared to mainframes. The iPhone is a usable design for the time when it was built as well. But compared to each other, which is the more usable design today?

Increasing usability often comes at the cost of flexibility. I was talking to someone at a fabrication lab about printer drivers for a laser etching machine. He said that installing the drivers for the device on Windows is easy but almost impossible on a Mac. I chuckled because the difficulty of installing a non-standard printer on a Mac is part of the reason why it’s easy to use for other kinds of printers. The printing subsystem traded usability with things like Bonjour printer installation over flexibility, like installing strange printers on a laptop.

Those trade offs extend into the hardware. Anyone that worked on PCs prior to Windows 95 knows all about fun things like IRQ conflicts, DIP switch settings for COM port addresses, and even more esoteric problems. We managed to get rid of those in the modern computing era but along with that went the ability to customize the device. You no longer have to do the dance of finding an available IRQ but you also can’t install a device that would conflict with another through hardware trickery.

By creating devices for the average user focused on usability you have to sacrifice the flexibility that makes them easier to fix. If you knew you were constantly going to need to be tweaking the jets on a carburetor you’d make it easy to access, right? But if a modern fuel injection system never needs to be adjusted except by a specialized professional why would you make it accessible to anyone that doesn’t have tools? You can see this in systems that use proprietary screws to keep users out of the system or glue parts together to prevent easy access.


Tom’s Take

I miss the ability to open up my laptop and fix issues with the add-in cards. The tinkerer in me likes to learn about how a system works. But I don’t miss the necessity to go in and do it. The usability of a system that “just works” is way more useful to me. It reminds me of my dad in some ways. He may have loved the ability to open up the engine and play with the carburetor but he also had to do it frequently to make things “work right”. In some ways, removing our ability to repair things in the IT space has forced manufacturers to build devices that don’t need to be frequently repaired. It’s not the optimal solution for sure, but the trade off it more than worth it in my mind.

In Defense of Subscriptions

It’s not hard to see the world has moved away from discrete software releases to a model that favors recurring periodic revenue. Gone are the days of a bi-yearly office suite offering or a tentpole version of an operating system that might gain some features down the road. Instead we now pay a yearly fee to use the program or application and in return we get lots of new things on a somewhat stilted cadence.

There are a lot of things to decry about software subscription models. I’m not a huge fan of the way that popular features are put behind subscription tiers that practically force you to buy the highest, most expensive one because of one or two things you need that can only be found there. It’s a callback to the way that cable companies put their most popular channels together in separate packages to raise the amount you’re paying per month.

I’m also not a fan of the way that the subscription model is a huge driver for profits for investors. If your favorite software program doesn’t have a subscription model just yet you’d better hope they never take a big investment. Because those investors are hungry for profit. Profit that is easier to see on a monthly basis because people are paying a fee for the software monthly instead of having big numbers pop up every couple of years.

However, this post is about the positive aspects of software subscriptions. So let’s talk about a couple of them.

Feature Creatures

If you’ve ever complained that an application or a platform doesn’t have a feature that you really want to see you know that no software is perfect. Developers either put in the features they think you want to see or they wait for you to ask for them and then race to include them in the next release. This push-pull model dominates the way that traditional software has been written.

How do those features get added to software? They do have to be written and tested and validated before they’re published. That takes time and resources. You need a team to add the code and tools to test it. You need time to make it all work properly. In other words, a price must be paid to make it happen. In a large organization, adding those features can be done if there is sufficient proof that adding them will recoup the costs or increase sales, therefore justifying their inclusion.

How about if no one wants to pay? You don’t have to look far for this one. Most of the comments on a walled garden app store are constantly talking about how “this app would be great if it had this feature” or “needs to do “X” then it’s perfect!” but no one wants to pay to have those features developed. If the developer is already charging a minimum for the app or giving it away in hope of making up the difference through ad revenue or something, how can we hope to encourage them to write the feature we want if we’re not willing to pay for it?

This is also the reason why you’re seeing more features being released for software outside of what you might consider a regular schedule. Instead of waiting for a big version release to pack in lots of new features in the hopes of getting customers to pay for the upgrade developers are taking a different approach. They’re adding features as they are finished to show people the value of having the subscription. This is similar to the model of releasing the new episodes of a series on a streaming service weekly instead of all at once. You get people subscribed for longer periods instead of doing it only long enough to get the feature they’re looking for. Note that this doesn’t cover licensing that you must hold to use the feature.

Respect for the Classics

One other side effect of subscription licensing is support for older hardware. You may think this sounds counterintuitive. However, the likelihood that an older model of hardware is going to be supported later in life is due to the fact that there is no longer a need to force upgrades to justify hardware development.

Yes, there are always going to be releases that don’t support older hardware. If it’s something that needs to use a new chip or a new hardware feature it’s going to be very difficult to export that back to a platform that doesn’t have the hardware and never will. It’s also harder to code the feature in such as way as to run hardware that has varying degrees of support and implementation capabilities. The fact that an iPhone 7 and an iPhone 13 can run the same version of iOS is a huge example of this.

More to the point, the driver to force hardware upgrades is less impactful. If you’re writing a new app or new piece of software it’s tempting to make the new features run only on the latest version of the hardware. That practically forces the users to upgrade to take advantage of the new kit and new apps. It feels disingenuous because the old hardware may still have had a few more years of life in it.

Another factor here is that the added revenue from the subscription model allows developers to essentially “pay” to support those older platforms. If you’re getting money from customers to support the software you have the resources you need to port it to older version as well as continuing to support those older platforms with things like security updates. You may not get your favorite switch supported for a decade now but you also don’t have to feel like you’re being forced to upgrade every three years either.


Tom’s Take

I go back and forth with subscription models. Some tools and platforms need them. Those are the ones that I use every day and make lots of sense to me to keep up with. Others feel like they’re using the lure of more frequent feature releases to rope users into paying for things and making it difficult to leave. When you couple that with the drive of investors to have regular recurring revenue it puts companies into a tough spot. You need resources to build things and you need regular revenue to have resources. You can’t just hope that what you’re going to release is going to be popular and worry about the rest later. I don’t know that our current glut of subscription models is the answer to all our issues. However, it’s not the most evil thing out there.

No Is A Complete Sentence

Has someone asked you to do something recently that you know you don’t have time to do but felt like you needed to do anyway? Or has someone tried to get you to help with something and impressed upon you just how important it is? You probably told them “yes” out of guilt or obligation or some other kind of negative emotion. Sure, you could have declined but you thought about how bad you would feel if someone did the same to you.

Let me tell you clearly. “No” is a complete sentence. It requires no explanation or defense. It is the only thing you need to say when you know you won’t be able to do something no matter how much the other party tries to get you to agree.

Everything Sucking Equally

If you know anything about QoS, you know that once a given circuit reaches the limitation for bandwidth you can no longer send additional information. What’s counterintuitive about this is most people would assume that if you try to squeeze one more stream or packet into the mix that only that last packet would be affected and everything else would work perfectly fine, right? Only one of the many would suck.

Sadly, all of the packets or flows on the circuit are affected in this situation. Adding just one more thing to the mix means all things are affected because the system has to process the problems all at once. You suffer everywhere because the interface couldn’t say “no” to that last packet.

In fact, the whole mantra behind QoS is prioritizing information before it hits a given interface because the interface is just going to send whatever it is given. Those packets will queue up or eventually be dropped if they can’t be processed. Likewise, if you are trying to do too many things at once you will eventually miss something important and make a mistake because you couldn’t handle everything at once. You need to be able to prioritize all the things that are going on and know when you hit a limit you can’t get past.

Where the challenge comes into play is when others try to add more to the interface without knowing you’re at maximum capacity. It’s easy for someone to ask you to do just one more little thing. In their minds it’s not a huge ask, right? In your mind you’ve already begun trying to juggle all the things that need to be changed to make this one little thing work with all the other things you’ve spent so much time prioritizing. Unfortunately, it’s too easy to just say “yes” to avoid uncomfortable conversations and try to fix the problems as they come up rather than turning away something you know would put you over your limit.

Taking No For an Answer

It’s easy to tell people to say “no”, right? I mean it is possibly the shortest sentence in the English language. However, it’s not the person saying it that usually has an issue. The people doing the asking are the ones that almost invariably are the ones trying to convince, cajole, or outright impress upon the person how critical it is that whatever this is get done in addition to all the other things that are going on.

For those that are asking the question and expecting a positive answer, let me ask you a question of my own: Why does this person need to do the task? There usually are very good reasons for it. Perhaps it’s something this person specializes in. Maybe it’s something that only they have knowledge about. It could perhaps even be their job responsibility to get it done. But the next question you need to ask is even more important.

If they must do this task, what can I do to help them?

The calling card of bad management types is to show up, assign a bunch of tasks that only other people should do, and then fly away to measure their productivity and comment on how nothing seems to be getting done. Instead, management should be asking how they can help. Is this something that someone else could do? Do you have the bandwidth to do the task? Is there another task on your plate that I can do for you that would help you to take care of this?

People are often very fully tasked with all the things they have to take care of. Thinking that you can sneak one more thing onto their schedule without impacting all of it smacks of hubris. What if someone started adding tasks to your plate instead? I doubt you’d like that. Even if you said no, what if it was the CEO or the Chairman of the Board telling you that you had to do it? You’d probably be just as upset, especially if it was a task you couldn’t delegate.

For the people out there like me, try this next time someone asks you to do something and you’re fully tasked or unable to clear enough to accomplish it. Say “no”. Don’t explain. Don’t justify. Don’t defend. Just. Say. No. Watch the other person’s reaction. Are they getting frustrated because you’re not saying anything? Are they coming back in a helpful manner trying to understand why you declined? Or are they more upset that they now have to go find someone else to do it instead? If they come to you with respect and understanding you can tell them why you declined and are unable to help. They may offer suggestions or try to find a way to make it work. The ones that get upset are usually the ones that wouldn’t have taken “no” for an answer no matter what. They are the ones you don’t need to waste your breath on.


Tom’s Take

I will admit this post is as much for me as it is for others. I am the world’s worst for taking on additional things when I know I don’t have the bandwidth to do it all. I don’t like to disappoint. I really want to keep people happy. And instead I end up failing because I overestimate my ability to get work done and underestimate how much others could do if they knew I needed help. Next time you need to tell someone you can’t do something, don’t spend a ton of effort figuring out how to counter their eventual arguments. Just say “no” and move on. If it’s important or something that only you can do they will find a way to make it work. Otherwise, you will have saved so much more effort because you used a complete sentence instead of a needless paragraph.

AI is a Promotion

When I worked at IBM as an intern, part of my job was writing a deployment script to help make our lives easier when installing new ThinkPads. In order to change an MTU setting on the token ring PCMCIA cards (long story), I had to write a script that iterated through all the possible combinations of adapters in the registry to find the one I was looking for and change the value.

Now, I was 22 at the time and green behind the ears, especially when it came to programming. I finally figured out that the most efficient way to do this in the language that I was using was a very deep nested if statement. It wasn’t my best work but it operated properly. I mentioned this to my mentors on my team with a remark of how hard it was to understand the logic at first. My comment was “You know, if it’s hard to read for anyone else then I never have to worry about gettin fired.”

To which the response was, “Yes, but you can never be promoted either.”

That sage wisdom brings me to the modern world and how AI can fix that issue.

Eternal Support

One of the first things you learn in IT is not to volunteer. If you know how to implement a technology or troubleshoot a specific issue then you become the go-to person for that problem. If you add a skill to the team like debugging Rust or configuring voice mail dial peers then you are the new owner for that particular skill.

This becomes annoying when you finally move past that skillset and you’re on to new and better things. If you are the person that knows how to extend database schemas or change auto attendant functions you are always going to be called upon to do those things. Rather than moving on to new challenges you will be called back to work on the things that no one else bothered to learn or couldn’t pawn off on someone else.

When you think about it, that’s part of the reason why so many entry-level positions start with some basics like VLAN programming or LUN configuration. Sure, you’re learning the basics and understanding how systems operate. But you’re also repeating the things that the junior person before you did. Why? Because they now have someone to do that work for them. And when the new person gets hired as a junior-level technician, you’re going to pass along those tasks to someone so they can learn and so you can move on. It’s the Circle of IT Life.

The reinforcement of knowledge is only so important to the organization. Yes, you need someone to keep the lights on and do the tasks regarded as menial by the senior teams. However, miring people in those tasks makes them feel undervalued after a while because no one wants to take them on. And, as above, if it’s something that no one else can be bothered to learn or take over you’re going to be stuck doing it until you leave or until the system in question is eventually replaced. And even then you’ll probably be asked to learn how to do the new thing because “this is your system”.

Learning, Not Thinking

The reason why I’m excited for applied AI in infrastructure and operations is because it will learn these menial tasks and do them as instructed every time without complaint or mistake. Yes, that means you need to train the algorithm correctly. Yes, that means you need to be on the lookout for changes and update accordingly when hardware changes or when procedure changes. Given those constraints AI will work for you, not against you.

When you move on to a new role you expect to face new challenges. If you move from a junior role to a senior role you want to work on harder things or solve new problems. You don’t want to get a new title with the same old work. If you change teams you want to experience new systems and implement new technology. You don’t want to be the cloud person that still deploys campus switches in wiring closets.

In a way, having AI take over the basic tasks of your job functions doesn’t remove your job. It promotes you to a new role. It could be that the first promotion is running the system that you implemented to do the work. A “train the trainer” kind of role, if you will. As soon as you can ensure that it is working correctly and that the rest of the team is aware of how to keep the engine running you can decide where you want to go next. You essentially have the freedom to learn and do and not have to be concerned about going back to doing the old things.

Is AI the Enemy?

AI doesn’t take away jobs. It takes away tasks. It streamlines processes and provides consistent, repeatable outcomes. If your job is a collection of tasks that need to be done then it is worth asking why it’s so easy for it to be replaced by an AI system. I’ve said on a number of occasions that there will always been room for jobs that AI can’t do, such as those that involve physical labor, as well as advanced thinking and creative problem solving.

Where AI does succeed is in the repeatable task department. If a role is comprised of repeatable tasks then the question becomes “why does this role exist?” If an algorithm can determine the best way to implement VLANs or offload clients to other devices then the job that was doing those roles needs to be examined. Can that person be encourage to do something else for the company? Can that role be reduced and given to someone with less experience? If those questions make you or someone on your team bristle, is that the fault of the AI? Or the fact of the job being less than ideal for the business?


Tom’s Take

AI can take away some of the unimportant and forgettable parts of your job and give you the freedom to do things that are more important to the business, possibly in a different role. Isn’t that the textbook definition of a promotion? Change makes people uncomfortable. It makes sense that no one wants to have their job taken away. But if you ask anyone in IT right now if they could get rid of 10-20% of the tasks in their job that they don’t like to do they’d agree in a heartbeat. AI isn’t going to remove your job. It’s going to give you the freedom to do something different. It’s also going to ensure you don’t have to keep getting called back to do that thing over and over again because no one else wants to learn it. I think it’s time we let new technologies like AI give everyone on the team the promotion they deserve.

Technical Debt or Underperforming Investment?

In this week’s issue of the Packet Pushers Human Infrastructure newsletter, there was an excellent blog post from Kam Lasater about how talking about technical debt makes us sound silly. I recommend you read the whole thing because he brings up some very valid points about how the way the other departments of the organization perceive our issues can vary. It also breaks down debt in a very simple format that takes it away from a negative connotation and shows how debt can be a leverage instrument.

To that end, I want to make a modest proposal to help the organization understand the challenges that IT faces with older systems and integration challenges. Except we need some new branding. So, I propose we start referring to technical debt as “underperforming technical investments”.

I’d Buy That For A Dollar

Technical debt is just a clever way to refer to the series of layered challenges we face from decisions that were made to accomplish tasks. It’s a burden we carry negatively throughout the execution of our job because it adds extra time to the process. We express it as debt because it’s a price that must be paid every time we need to log in to the old accounting system to make changes or we have to wake up on the third Sunday of the month to reboot the access points because of a software bug that we can’t fix.

As Lasater points out, the financial departments look at debt differently. It’s not always negative. Commercial paper allows for purchasing power beyond cash-on-hand. Mortgages and loans allow us to buy houses and cars that enable us to do much more with our lives. Reasonable debt can be good so long as what we get out of it is a net positive. Debt doesn’t become an issue until there’s too much of it for the return we get, which eventually leads to bankruptcy.

Let’s point out some of the challenges we face with technical things that we refer to as debt. We usually use it in reference to outdated systems or slower equipment that doesn’t allow us to do our jobs as effectively as possible. Unlike a house which still provides the value of a dwelling at any age given reasonable maintenance or a car that still operates with the same maintenance, technology changes more rapidly. The original iPhone is unable to operate in a modern environment because of outdated software or inability to connect to the mobile network.

In consumer tech, the idea of technical debt doesn’t exist. Because when things are “slow” or “broken” they get discarded and people spend money to get something new. Someone that is willing to live with a shattered phone screen because they don’t want to pay to fix it might be willing to wait another two months to get a new device because it supports the latest OS updates or has a better camera. The chase for new features is usually enough of a driver to get people to upgrade.

In the enterprise, the infrastructure equipment is expensive enough that we need to recognize the value of what we installed. We can’t just swap out all the switches in three years if we spent hundreds of thousands of dollars on them. Likewise, enterprise tech vendors are more likely to provide patches and updates for this gear knowing that customers are going to hold on to it for longer periods of time. And even then, just because something is EoL doesn’t mean it’s End of Use.

However, the disconnect between these two things comes when we talk about how equipment that is functional is also causing issues with our job. Maybe it’s an older, slower switch that drops more packets than the rest of the newer gear. It’s a problem but not big enough to justify buying a new one. It could be an older wireless controller that doesn’t have the capability to run the newest code because of an older CPU. We have gear that works but it doesn’t work as well as it could. But we also don’t have enough justification to get new stuff because the old things haven’t broken completely yet.

Putting Your Money Where Their Mouth Is

As Lasater says in the above article, talking about how it’s hard to do your job because everything is old doesn’t resonate with management. No one really wants to hear a department head whining about how their job is tough because they don’t have the latest toys. Admit it, you’d be upset if your CEO told you they couldn’t answer their email because they don’t have the newest MacBook Pro. Capable means functional in every enterprise.

However, I think the challenge we face and the solution to the problem is how we frame the discussion of the challenge itself. We talk about it as a debt that we feel saddled with. It’s something we did because we had to or something someone else chose to do that we have to live with. It feels like we’re paying a tax every day over something that we don’t like. But choices need to be made and we have to work with what we have. Unless we can provide for a way to get people to understand the tradeoffs.

Hence, my proposal above. First, we stop referring to IT infrastructure gear as “technical debt”. It’s not something we bought and now have to deal with. Our accounting departments are amortizing the acquisition costs of the equipment over a period of time and writing it off of taxes against recognized revenue. There is a real dollar amount attached to every month of the lifetime of a switch or a server. That’s how finance sees your equipment. It’s not debt.

It’s a technical investment.

That’s your key to helping them understand the challenges you face. You’re not complaining about doing your job more slowly. Instead, you’re pointing out that you are investing a resource (your time) into a process that could have reduced resource requirements (again, your time and job execution time) if they would just invest in a different solution.

You’re not telling them they bought a lemon. Instead, you’re just telling them that the thing they invested in years ago isn’t performing as well as it could based on new data. If you need to break it down even further for your executive team you can just equate it to a home loan refinancing. If interest rates have dropped since you bought your home, doesn’t it make a ton of sense to refinance and take advantage of the savings? Likewise, if the speed or power of a system has increased in the past four years doesn’t it make sense to invest in something new?

When you change the discussion to focus on investment of resources instead of dealing with debt you change the way that the people will look at the return on that investment. If you just talk about debt the executives are going to easily be able to dismiss you because there is no upside to the conversation. They have to pay money to replace things so why spend it? If you talk about how much they could save on labor or how much more efficiently things could run if they made some changes or bought something new then that is harder to ignore. If their existing investment is underperforming some baseline on the stock market they’re going to want to move it right away. If the company’s stock is underperforming you can better believe some of the shareholders are going to want to move their investment too.

Here Comes the Money

One word of warning here. You can’t go in to this conversation with vague assurances that spending more money will make money. You have to come with numbers that support your case. Some of them are easy. You know what the new system will cost. You know how much time it will take to implement it. What you need to bring is the cost of what you are paying now to do things inefficiently.

If your team of 5 has to spend two extra hours a week doing something because the system is old or doesn’t work well with others then you have ten hours of lost time. You need to figure out what the value of your time is. Big note here: Don’t just divide your yearly salary by 2000 and take the averages. That’s what you’re getting paid. That’s the debt that the company incurs to keep you on staff. Instead, find out what your rate is. If you are billed at a higher rate than your earnings, which is almost a guarantee, use that number instead. If you’re an engineer for a reseller your hourly billing rate is easy to find. If you work in corporate IT the rate is harder to figure out but if you need a rule of thumb just figure out what your hourly pay rate is (yearly salary divided by 2000 hours per year) and double it. That’s the kind of return that any company would love to have on an investment. If it’s costing the company that much to do something inefficiently then you can make your case to get it fixed or replaced.

Lastly, make sure to record the changes and the results if you manage to make it happen. It’s easy to chart when you take more time to do something to prove a point. But it’s easy to forget to do it when you have what you want. Eventually, someone that manages investments needs to know if it paid off. If there’s a simple number like a stock price it’s cut-and-dried. If there’s more to the calculation you need to do the work to prove why it’s better now. And you want to keep a running total so you can provide it on demand when asked. Just tell them you have more time to track those kinds of things now that they made a wiser investment.


Tom’s Take

No one likes debt. Even the best debt is still an obligation to pay back to someone. However, investments are something positive. Yes, they still require resources to be exchanged to receive a good or service. However, changing the terminology changes the perception of the result. Debts are incurred and paid back begrudgingly. Investments grow and provide additional resources throughout their lives. And, importantly, when an investment isn’t paying off the way to fix it is to reinvest. It’s a clever trick but one that should work much better than just whining about drowning in debt.

Who Wants to Be Supported Forever?

I saw an interesting thread today on Reddit talking about using networking equipment past the End of Life. It’s a fun read that talks about why someone would want to do something like this and how you might find yourself in some trouble depending on your company policies and such. But I wanted to touch on something that I think we skip over when we get here. What does the life of the equipment really mean?

It’s a Kind of Magic

As someone that uses equipment of all kinds, the lifetime of that equipment means something different for me than it does for vendors. When I think of how long something lasts I think of it in terms of how long I can use it until it is unable to be repaired any further. A great example of this is a car. All of my life I have driven older used cars that I continue to fix over and over until they have a very high mileage or my needs change and I must buy something different.

My vehicles don’t have a warranty or any kind of support, necessarily. If I need something fixed I either fix it myself or I take it to a mechanic to have it fixed and pay the costs associated with that. I’m not the kind of person that will get rid of a car just because the warranty has run out and it’s no longer under support.

The market of replacement parts and mechanics is made for people like me. Why buy something new when you can buy the parts to repair what you have? Sadly, that market exists for automobiles but not for IT gear. It’s hard to pull a switch apart and resolder capacitors when you feel like it. Most of the time you want to replace something that has failed and is end-of-life, you need to have a spare of the same kind of equipment sitting on the shelf. You can put the configuration files you need on it and put it in place and just keep going. The old equipment is tossed aside or recycled in some way.

Infrastructure gear will work well past the End of Support (EoS) or End of Life (EoL) dates. It will keep passing packets until something breaks, either the hardware in the ports or the CPU that drives it. Maybe it’s even a power supply. Usually it’s not the end of the life of the hardware that causes the issues. Instead, it’s the software concerns.

Supported Rhapsody

I’d venture a guess that most people reading this blog have some kind of mobile device sitting in their junk drawer or equipment box that works perfectly fine yet isn’t used because the current version of software doesn’t support that model. Software is a bigger determining factor the end of life of IT equipment than anything else.

Consumer gear needs to be fast to keep users happy. Phones, laptops, and other end user devices have to keep up with the desires of the people running applications and playing games and recording video. These devices iterate quickly and fall out of support just as fast. Your old iPhone or Galaxy probably won’t run the latest code which has a feature you really want to use so you move on to something newer.

Infrastructure gear doesn’t have software go out of fashion quite as quickly as a mobile phone but it does have another issue that causes grief: security patches. You may not be chasing a new feature in a software release but you’re either looking to patch a bug that is affecting performance or patch a security hole that has the potential to cause issues for your organization.

Security patches for old hardware are a constant game of cat-and-mouse. Whether it’s an old operating system running important hardware terminals or the need to keep an old terminal running because the application software doesn’t work on anything newer IT departments are often saddled with equipment that’s out of date and insecure. Do you keep running it, hoping that there will still be patches for it? Or do you try to move to something newer and hope that you can make things work? Anyone that is trying to use software that requires versions of Microsoft Internet Explorer knows that pain can last for years.

The real issue here doesn’t have anything to do with support of the equipment or the operating system. Instead, it has everything to do with the support that you can provide for it. A mechanic isn’t magical. They learn how to get parts for cars and fix the problems as they arise. They become the support structure instead of the dealership that offers the warranty. Likewise, as an IT pro you become the support structure for an old switch or old operating system. If you can’t download patches for it you either need to provide a workaround for issues or find a way to create solutions to address it. It’s not end of support as much as it’s end of someone else’s support.


Tom’s Take

I use things until they don’t work. Then I fix them and use them more. It’s the way I was raised. I have a hard time getting new things simply because they’re supported or a little bit faster. I might upgrade my phone to get a new feature but you can bet I’m going to find a way to use my old one longer, either by giving it to one of my kids or using it in a novel way. I hate getting rid of technology that has some use left in it. End of Life for me really does mean the moment when it stops sending bits or storing data. As long as there is no other conflict in the system you can count on me extending the life of a device long past the date that someone says they don’t want to deal with it any more.

The Demise of G-Suite

In case you missed it this week, Google is killing off the free edition of Google Apps/G-Suite/Workspace. The short version is that you need to convert to a paid plan by May 1, 2022. If you don’t you’re going to lose everything in July. The initial offering of the free tier was back in 2006 and the free plan hasn’t been available since 2012. I suppose a decade is a long time to enjoy custom email but I’m still a bit miffed at the decision.

Value Added, Value Lost

It’s pretty easy to see that the free version of Workspace was designed to encourage people to use it and then upgrade to a paid account to gain more features. As time wore on Google realized that people were taking advantage of having a full suite of 50 accounts and never moving, which is why 2012 was the original cutoff date. Now there has been some other change that has forced their hand into dropping the plan entirely.

I won’t speculate about what’s happening because I’m sure it’s complex and tied to ad revenue and privacy restrictions that people are implementing that is reducing the value of the data Google has been mining for years. However, I can tell you that the value of what they’re offering with their entry-level business plan isn’t as valuable as they might think.

The cheapest Google Workspace plan available is $6 per user per month. It covers the email and custom domain that was the biggest attraction. It also has a whole host of other features:

  • Google Meet, which I never use when Zoom/Webex/Teams exist
  • Google Drive, which is somewhat appealing except for when no one wants to use Docs or Sheets and Dropbox is practically a standard and still free
  • Chat, which makes me laugh because it’s probably the next thing to get killed off in favor of some other messaging platform that will get abandoned in six months

Essentially, Google is hoping to convince me to pay for their service that has been free this entire time by giving me things I don’t use now and probably won’t use in the future? Not exactly a good selling model.

Model Citizens

I’ve heard there is a plan for trying to give loyal customers a discount for the first year of service to ease the transition but that’s not going to cut it for most. Based on the comments I’ve seen most people are upset that they have purchases from Google tied to an account they can’t transfer away from as well as the possibility that whatever happens next is going to be shut down anyway. I mean, Killed by Google is starting to look like a massive graveyard at this point.

I’m willing to concede at this point that the free tier of Google Workspace is gone and won’t be coming back. What I’m not ready to give in on is the model that you’re forcing me to pay for and use other services because you have a target revenue number to hit and you keep throwing useless stuff in to make it seem valuable. You’re not transitioning us to a new model. You’re ramming the existing one down our throats because you need users for those other services that are paying.

Want to extend some goodwill to the community? Offer us a solution that gives us what we want for a reasonable pricing model? How about email without video chat and Drive for $3 per month per user? How about allowing me to cut out the junk and reduce my spend. How about giving me something with other value based on how I use your service and not how you think I should be using it?


Tom’s Take

I realize I’m just tilting at windmills in this whole mess but It’s frustrating. I’m totally prepared to never see a resolution to this issue because Google has decided it’s time to kill it off. Yes, I got a decade of free email hosting out of the deal. I got a lot of value for what I invested. I even realize that Google can’t keep things free forever. I just wish there was a way for me to pay them for what I want and not have to pay more for things that are useless to me. Technology marches on and new models always supplant old ones. The only constant is change. But change is something we should be able to process and accept. Not have it forced upon us to ensure someone is using Google Meet.