A Gift Guide for Sanity In Your Home IT Life

If you’re reading my blog you’re probably the designated IT person for your family or immediate friend group. Just like doctors that get called for every little scrape or plumbers that get the nod when something isn’t draining over the holidays, you are the one that gets an email or a text message when something pops up that isn’t “right” or has a weird error message. These kinds of engagements are hard because you can’t just walk away from them and you’re likely not getting paid. So how can you be the Designated Computer Friend and still keep your sanity this holiday season?

The answer, dear reader, is gifts. If you’re struggling to find something to give your friends that says “I like you but I also want to reduce the number of times that you call me about your computer problems” then you should definitely read on for more info! Note that I’m not going to fill this post will affiliate links or plug products that have sponsored anything. Instead, I’m going to just share the classes or types of devices that I think are the best way to get control of things.

Step 1: Infrastructure Upgrades

When you go visit your parents for Thanksgiving or some other holiday check in, are they still running the same wireless network they got when they got their high-speed Internet? Is their Wi-Fi SSID still the default with the password printed on the side of the router/modem combo? Then you’re going to want to upgrade their experience to keep your sanity for the next few holidays.

The first thing you need to do it get control of their wireless setup. You need to get some form of wireless access point that wasn’t manufactured in the early part of the century. Most of the models on the market have Wi-Fi 6 support now. You don’t need to go crazy with a Wi-Fi 6E model for your loved ones right now because none of their devices will support it. You just need something more modern with a user interface that wasn’t written to look like Windows 3.1.

You also need to see about an access point that is controlled via a cloud console. If you’re the IT person in the group you probably already use some form control for your home equipment. You don’t need a full Meraki or Juniper Mist setup to lighten your load. That is, unless you already have one of those dashboards set up and you have spare capacity. Otherwise you could look at something like Ubiquiti as a middle ground.

Why a cloud controller AP? Because then you can log in and fix things or diagnose issues without needing to spend time talking to less technical users. You can find out if they have an unstable Internet connection or change SSID passwords at the drop of a hat. You can even set up notifications for those remote devices to let you know when a problem happens so you can be ready and waiting for the call. And you can keep tabs on necessary upgrades and such so you aren’t fielding calls when the next major exploit comes out and your parents call you asking if they’re going to get infected by this virus. You can just tell them they’re up-to-date and good to go. The other advantage of this method is that when you upgrade your own equipment at home you can just waterfall the old functional gear down to them and give them a “new to you” upgrade that they’ll appreciate.

Step 2: Device Upgrades

My dad was notorious for using everything long past the point of needing to be retired. It’s the way he was raised. If there’s a hole you patch it. If it breaks you fix it. If that fix doesn’t work you wrap it in duct tape and use it until it crumbles to dust. While that works for the majority of things out there it does cause issues with technology far too often.

He had a iPad that he loved. He didn’t use it all day, every day but he did use it frequently enough to say that it was his primary computing device. It was a fourth-generation device, so it fell out of fashion a few years ago. When he would call me and ask me questions about why it was behaving a certain way or why he couldn’t download some new app from the App Store I would always remind him that he had an older device that wasn’t fast enough or new enough to run the latest programs or even operating software. This would usually elicit a grumble or two and then we would move on.

If you’re the Designated IT Person and you spend half your time trying to figure out what versions of OS and software are running on a device, do yourself a favor and invest in a new device for your users just to ease the headaches. If they use a tablet as their primary computing device, which many people today do, then just buy a new one and help them migrate all the data across to the new one while you’re eating turkey or opening presents.

Being on later hardware ensures that the operating system is the latest version with all the patches for security that are needed to keep your users safe. It also means you’re not trying to figure out what the last supported version of the software was that works with the rest of the things. I’ve played this game trying to get an Apple Watch to connect to an older phone with mismatched software as well as trying to get support for newer wireless security on older laptops with very little capability to do much more than WPA1. The amount of hours I burned trying to make the old junk work with the new stuff would have been better served just buying a new version of the same old thing and getting all their software moved over. Problems seem to just disappear when you are running on something that was manufactured within the last five years.

Step 3: Help Them Remember

This is probably my biggest request: Forgotten passwords. Either it’s the forgotten Apple ID or maybe the wireless network password. My parents and in-laws forget the passwords they need to log into things all the time. I finally broke down and taught them how to use a password management tool a few years ago and it made all the difference in the world. Now, instead of them having to remember what their password was for a shopping site they can just set it to automatically fill everything in. And since they only need to remember the master password for their app they don’t have to change it.

Better yet, most of these apps have a secure section for notes. So all those other important non-password things that seem to come up all the time are great to put in here. Social Security Numbers, bank account numbers, and so much more can be put in one central location and made easy to access. The best part? If you make it a shared vault you can request access to help them out when they forget how to get in. Or you can be designated as a trusted party that can access the account in the event of a tragedy. Getting your loved ones used to using password vaults now makes it much easier to have them storing important info there in case something happens down the road that requires you to jump in without their interaction. Trust me on this.


Tom’s Take

Your loved ones don’t need knick knacks and useless junk. If you want to show them you love them, give them the gift of not having to call you every couple of days because they can’t remember the wireless password or because they keep getting this error that says their app isn’t support on this device. Invest in your sanity and their happiness by giving them something that works and that has the ability for you to help manage it from the background. If you can make it stable and useful and magically work before they call you with a problem you’re going to find yourself a happier person in the years to come.

Getting In Front of Future Regret

Yesterday I sat in on the keynote from Commvault Connections21 and participated in a live blog of it on Gestalt IT. There was a lot of interesting info around security, especially related to how backup and disaster recovery companies are trying to add value to the growing ransomware issue in global commerce. One thing that I did take away from the conversation wasn’t specifically related to security though and I wanted to dive into a bit more.

Reza Morakabati, CIO for Commvault, was asked what he thought teams needed to do to advance their data strategy. And his response was very insightful:

Ask your team to imagine waking up to hear some major incident has happened. What would their biggest regret be? Now, go to work tomorrow and fix it.

It’s a short, sweet, and powerful sentence. Technology professionals are usually focused on implementing new things to improve productivity or introduce new features to users and customers. We focus on moving fast and making people happy. Security is often seen as running counter to this ideal. Security wants to keep people safe and secure. It’s not unlike the parents that hold on to their child’s bicycle after the training wheels come off just to make sure the kids are safe. The kids want to ride and be free. The parents aren’t quite sure how secure they’re going to be just yet.

Regret Storming

Thought exercises make for entertaining ways to scare yourself to death some days. If you spend too much time thinking about all the ways that things can go wrong you’re going to spend far too much energy focused on the negative aspects of your work. However, you do need to occasionally open yourself up to the likelihood that things are going to go wrong at some point.

For the thought exercise above, it’s not crucial to think about how they could go wrong. It’s more important to think about what could be the worst thing that could happen as a result of those bad things and how much you’ll regret it. You need to identify those areas and try to figure out how they can be mitigated.

Let me give you a specific example from my area. In May 2013 a massive tornado ripped through Moore, OK just north of where I live. It was a tragic event that had loss of life. People were displaced and homes and businesses were destroyed. One of the places that was damaged severely was the Moore Public Schools administration building. In the aftermath of trying to clean up the debris and find survivors, one of my friends that worked for an IT vendor told me he spent hours helping sift through the rubble of the building looking for hard disk drives for the district’s servers. Why? Because the tornado had struck just before the payroll for the district’s teachers and staff was due to be run. Without the drives they couldn’t run payroll or print paychecks for those employees. With an even greater need to have funds to pay for food or start repairs on their homes you can imagine that not getting paid was going to be a big deal for those educators and staff.

There are a lot of regrets that came out of the May 2013 tornado. Loss of life and loss of property are always at the top of the list. The psychological damage of enduring something like that is also a huge impact. But for the school district one of the biggest regrets they faced was not having a contingency plan for what to do about paying their employees to help them deal with the disaster. It sounds small in comparison to the millions of dollars of damage that happened but it also represents something important that can be controlled. The school system can’t upgrade the warning system or build businesses that can withstand the most powerful storms imaginable. But they can fix their systems to prevent teachers from going without resources in the event of an emergency.

In this case, the regret is not being able to pay teachers if the district data center goes down. How could we fix that regret today if we had imagined it beforehand? We could have migrated the data center to the cloud so no one weather event could take it out. Likewise, we could have moved to a service that provides payroll entry and check printing that could be accessed from anywhere. We could also have encouraged our teachers and employees to use direct deposit functions to reduce the need to physically print checks. Technology today provides us with a number of solutions to the regret we face. We can put together plans to implement any one of them quickly. We just need to identify the problem and build a resolution for it.

Building Your Future

It’s not easy to foresee every possible outcome. Nor should it be. But if you focus on the feelings those unknown outcomes could bring you’ll have a much better sense for what’s important to protect and how to go about doing it. Are you worried your customer data is going to be stolen and shared on the Internet? Then you need to focus your efforts on protecting it. Are you concerned your AWS bill is going to skyrocket if someone steals your credentials and starts borrowing your resource pool? Then you need to have governance in place to prevent unauthorized users from doing that thing.

You don’t have to have a solution for every possible regret. You may even find that some of the things you thought you might end up regretting are actually pretty mild. If you’re not concerned about what would happen to your testing environment because you can just clone it from a repository then you can put that to bed and not worry about it any longer. Likewise, you may discover some regrets you didn’t anticipate. For example, if you’re using Active Directory credentials to back up your server data, you need to make sure you’re backing up Active Directory as well. You’re going to find yourself infuriated if you have the data you need to get back to business but it’s locked behind cryptographic locks that you can’t open because someone forgot to back up a domain controller.


Tom’s Take

I’ve been told that I’m somewhat negative because I’m always worried about what could go wrong with a project or an event. It’s not that I’m a pessimist as much as I’ve got a track record for seeing how things can go off the rails. Thanks to Commvault I’m going to spend more time thinking of my regrets and trying to plan for them to be mitigated ahead of time so all the possible ways things could fail won’t consume my thoughts. I don’t have to have a plan for everything. I just need to get in front of the regrets before I feel them for real.

Chip Shortages Aren’t Sweet for Networking

Have you tried to order networking gear recently? You’re probably cursing because the lead times on most everything are getting long. It’s not uncommon to see lead times on wireless access points or switch gear reaching 180 days or more. Reports from the Internet say that some people are still waiting to get things they ordered this spring. The prospect of rapid delivery of equipment is fading like the summer sun.

Why are we here? What happened? And can we do anything about it?

Fewer Chips, More Air

The pandemic has obviously had the biggest impact for a number of reasons. When a fabrication facility shuts down it doesn’t just ramp back up. Even when all the workers are healthy and the city where it is located is open for business it takes weeks to bring everything back online to full capacity. Just like any manufacturing facility you can’t just snap your fingers and get back to churning out the widgets.

The pandemic has also strained supply chains around the world. Even if the fabs had stayed open this entire time you’d be looking at a shortage of materials to make the equipment. Global supply chains were running extremely lean in 2019 and exposing one aspect of them has created a cascade effect that has caused stress everywhere. The lack of toilet paper or lunchmeat in your grocery store shows that. Even when the supply is available the ability to deliver it is impacted.

The supply chain problem also belies the issue on the other side of the shipping container. Even if the fabs had enough chips to sell to anyone that wanted them it’s hard to get those parts delivered to the companies that make things. If this were simply an issue of a company not getting the materials it needed to make a widget in a reasonable time there wouldn’t be as much issue. But because these companies make things that other companies use to make things the hiccups in the chain are exacerbated. If TSMC is delayed by a month getting a run of chips out, that month-long delay only increases for those down the line.

We’ve got issues getting facilities back online. We’ve got supply chains causing problems all over the place. Simple economics says we should just build more facilities, right? The opportunity costs of not having enough production around means we have ample space to make more of the things we need and profit. You’re right. Companies like Intel are bringing new fabs online as fast as they can. Sadly, that is a process that is measured in months or even years. The capacity we need to offset the disruption to the chip market should have been built two years ago if we wanted it ready now.

All of these factors are mixed into one simple truth. Without the materials, manufacturing, or supply chain to deliver the equipment we’re going to be left out in the cold if we want something delivered today. Just in Time inventory is about to become Somewhere in Time inventory. We’re powerless to change the supply chain. Does that means we’re powerless to prevent disruption to our planning process?

Proactive Processes

We may not be able to assemble networking gear ourselves to speed up the process but we are far from helpless. The process and the planning around gear acquisition and deployment has to change to reflect the current state of the world. We can have an impact provided we’re ready to lead by example.

  • Procure NOW: Purchasing departments are notorious for waiting until the last minute to buy things. Part of that reasoning is that expenditures are worth less in the future than right now because those assets are more valuable today gaining interest or something. You need to go to the purchasing department and educate them about how things are working right now. Instead of them sitting on the project for another few months you need to tell them that the parts have to be ordered right now in order for them to be delivered in six or seven months. They’re going to fight you and tell you that they can just wait. However, we all know this isn’t going to clear up any time soon. If they persist in trying to tell you that you need to wait just have them try to go car shopping to illustrate the issue. If you want stuff by the end of Q1 2022, you need to get that order in NOW.
  • Preconfigure Things However You Can: If you’re stuck waiting six months to get switches and access points, are you going to be stuck waiting another month after they come in to configure them? I hope that answer is a resounding “NO”. There are resources available to make sure you can get things configured now so you’re not waiting when the equipment is sitting on a loading dock somewhere. You need to reach out to your VAR or your vendor and get some time on lab gear in the interim. If you ordered a wireless controller or a data center switch you can probably get some rack time on a very similar device or even the exact same one in a lab somewhere. That means you can work on a basic configuration or even provision things like VLANs or SSIDs so you’re not recreating the wheel when things come in. Even if all you have is a skeleton config you’re hours ahead of where you would be otherwise. And if the VAR or vendor gives you a hard time about lab gear you can always remind them that there are other options available for the next product refresh.
  • Minimum Viable Functionality: All this advice is great for a new pod or an addition to an existing network that isn’t critical. What if the gear you ordered is needed right now? What if this project can’t wait? How can you make things work today with nothing in hand? This is a bit trickier because it will require duplicate work. If you need to get things operational today you need to work with what you have today. That means you may have to salvage an old lab switch or pull something out of production and reduce available ports until the gear can arrive. It also means you’re going to have to backup the old configs, erase them completely (don’t forget about the VLAN database and VTP server configurations), and then put on the new info. When the new equipment comes in you’re going to have to do it all over again in reverse. It’s more work but it leads to things being operational today instead of constantly telling someone that it’s going to be a while. If you’re a VAR that’s doing this for a customer, you’d better make it very clear this is temporary and just a loan. Otherwise you might find your equipment being a permanent addition even after everything comes in.

Tom’s Take

The chip shortage is one of those things that’s going to linger under the best of circumstances. We’re going to be pressed to get gear in well into 2022. That means delayed projects and lots of arguing about what’s critical and what’s not. We can’t fix the semiconductor sector of the market but we can work to make sure that the impact felt there is the only one that impacts us right now. The more we do ahead of time to make things smooth the better it will be when it’s finally time to make things happen. Don’t let the lack of planning on the part of the supply chain sour your outlook on doing your role in networking.

APIs and Department Stores

This week I tweeted something from a discussion we had during Networking Field Day that summed up my feelings about the state of documentation of application programming interfaces (APIs):

I laughed a bit as I wrote it because I’ve worked in department stores like Walmart in the past and I know the reasons why they tend to move things around. Comparing that to the way that APIs are documented is an interesting exercise in how people think about things like new capabilities and notification of changes.

Branding Exercises

In case you weren’t aware, everything in your average department store is carefully planned out. The things placed in the main aisles are decided on weeks in advance due to high traffic. The items placed at the ends of the aisles, or endcaps, are placed there to highlight high margin items or things that are popular enough to be sought out by customers. The makeup of the rest of the store is determined by a lot of metrics.

There are a few restrictions that have to be taken into account. In department stores with grocery departments, the locations of the refrigerated sections must be around the outside because of power requirement. Within those restrictions, plans put the high traffic items in the back of the store to require everyone to walk past all the other stuff in hopes they might buy it. That’s why the milk and bread and electronics areas are always the furthest away from the front of the store. You’re likely headed there anyway so why not make you work for it?

Every few months the store employees receive new floor plans that move items to different locations. Why would they do that? Well, those metrics help them understand where people are more likely to purchase certain items. Those metrics also tell the planners what items should be located together as well, which is how the whole aisle is planned out. Once everything gets moved they start gathering new metrics and find out how well their planning works. Aside from the inevitable grumbles. Even with some fair warning no one is happy when you find out something has moved.

Who Needs Documentation?

You might think that, on the surface, there’s not much similarity between a department store aisle and an API. One is a fixture. The other is code. Yet, think about how APIs are typically changed and you might find some of the parallels. Change is a constant in the world of software development, after all.

The APIs that we used a decade ago are almost assuredly different from the ones we program for today. Every year brings updated methods, new functions, and even changes in programming languages or access methods. How can you be sure that developers are accessing the latest and greatest technology that you’ve put into place? You can’t just ask them. Instead, you have to deprecate the methods that you don’t want them to use any longer.

Ask any developer writing for a API about deprecation and you’re probably going to hear a string of profanity. Spending time to write a perfectly good piece of software only to have it wrecked by someone’s decision to do things differently is infuriating to say the least. Trying to solve a hard problem with a novel concept is one thing. Having to do it all over again a month later when a new update is released is even more infuriating.

It’s the same fury that you feel when the peanut butter is moved from aisle four to aisle eight. How dare you! It took me a week last time to remember where it was and now you’ve gone and moved it. Just like when I spent all that time learning which methods to query to pull the data I needed for my applications.

No matter how much notice you give or how much you warn people that change is coming they’re always going to be irritated at you for making those changes. It feels like a waste of effort to need to rewrite an interface or to walk a little further in the store to locate the item you wanted. Humans aren’t fond of wasted effort or of needing to learn new things without good reason.

Poor API documentation is only partly to blame for this. Even the most poorly documented API will eventually be mapped out by someone that needs the info. It’s also the fact that the constant change in methods and protocols forces people to spend a significant amount of time learning the same things over and over again for very little gain.

The Light at the End of the Aisle

Ironically enough, both of these kinds of issues are likely to be solved in a similar way. Thanks to the large explosion of people doing their shopping online or with pickup and delivery services there is a huge need to have things more strictly documented and updated very frequently. It’s not enough to move the peanut butter to a better location. Now you need to update your online ordering system so the customers as well as the staff members pulling it for a pickup order can find it quickly and get more orders done in a shorter time.

Likewise, the vast number of programs that are relying on API calls today necessitate that older versions of functionality are supported for longer or newer functions are more rigorously tested before implementation. You don’t want to disable a huge section of your userbase because you deprecated something you didn’t like to maintain any longer. Unless you are the only application in the market you will find that creating chaos will just lead to users fleeing for someone that doesn’t upset their apple cart on a regular basis.


Tom’s Take

Documentation is key for us to understand change. We can’t just say we changed something. We have to give warning, ensure that people have seen the warning, tell them we’ve changed it, and then give them some way to transform the old way of things into the new one. And even that might not be enough. However, the pace of change that we’re seeing also means that rapid changes may not even be required for much longer. With people choosing to order online and never step foot inside the store the need to change the shelves frequently may be a thing of the past. With new methods and languages being developed so rapidly today it may be much faster to rewrite everyone on a new API and leave the old one intact instead of forcing developers to look at technology that is years old at this point. The delicious irony of the people forcing change on us to need to accept change themselves is something I’d happily shop for.

Slow and Steady and Complete

StepTiles

I was saddened to learn last week that one of my former coworkers passed away unexpectedly. Duane Mersman started at the same time I did at United Systems and we both spent most of our time in the engineering area working on projects. We worked together on so many things that I honestly couldn’t keep count of them if I tried. He’s going to be missed by so many people.

A Hare’s Breadth

Duane was, in many ways, my polar opposite at work. I was the hard-charging young buck that wanted to learn everything there was to know about stuff in about a week and just get my hands dirty trying to break it and learn from my mistakes. If you needed someone to install a phone system next week with zero formal training or learn how iSCSI was supposed to operate based on notes sketched on the back of a cocktail napkin I was your nerd. That meant we could often get things running quickly. It also meant I spent a lot of time trying to figure out why things weren’t working. I left quite a few forehead-shaped dents in data center walls.

Duane was not any of those things. He was deliberate and methodical. He spent so much time researching technology that he knew it backwards and forwards and inside out. He documented everything he did while he was working on it instead of going back after the fact to scribble down some awkward prose from his notes. He triple checked all his settings before he ever implemented them. Duane wouldn’t do anything until he was absolutely sure it was going to work. And even then he checked it again just to be sure.

I used to joke that we were two sides of the same coin. You sent me in to clean things up. Then you sent Duane in to clean up after me. I got in and out quickly but I wasn’t always the most deliberate. Duane would get in behind me and spend time making sure whatever I did was the right way. I honestly felt more comfortable knowing he would ensure whatever I did wasn’t going to break next week.

Turtle Soup

Management knew how to use us both effectively. When the customer was screaming and needed it done right now I was the guy. When you wanted things documented in triplicate Duane was the right man for the job. I can remember him working on a network discovery diagram for a medical client that was so detailed that we ended up framing it as a work of art for the customer. It was something that he was so proud of given the months that he toiled away on it.

In your organization you need to recognize the way that people work and use them effectively. If you have an engineer that just can’t be rushed no matter what you need to find projects for them to work on that can take time to work out correctly. You can’t rush people if they don’t work well that way. Duane had many gears but all of them needed to fit his need to complete every part of every aspect of the project. Likewise, hard chargers like me need to be able to get in and get things done with a minimum of distraction.

Think of it somewhat like an episode of The Witcher. You need a person to get the monsters taken care of but you also need someone to chronicle what happened. Duane was my bard. He documented what we did and made sure that future generations would remember it. He even made sure that I would remember the things that we did later when someone asked a question about it or I stated blaming the idiot that programmed it (spoiler alert: I was that idiot).

Lastly, Duane taught me the value of being a patient teacher. When he was studying to take his CCNP exams he spent a significant amount of time on the SWITCH exam learning the various states of spanning trees. I breezed through it because it mostly made sense to me. When he went through it he lobbed up every example and investigated all the aspects of the settings. He would ask me questions about why something behaved the way it did or how a setting could mess things up. As he asked me what I thought I tried to explain how I saw it. My explanations created more questions. But those questions helped me investigate why things worked the way they did. His need to know all about the protocol made me understand it at a more fundamental level than just passing an exam. He slowed me down and made sure I didn’t miss anything.


Tom’s Take

Duane was as much a mentor in my career as anyone. We learned from each other and we made sure to check each other’s work. He taught me that slow and steady is just as important as getting things done at warp speed. His need to triple check everything led me to do the same in the CCIE lab and is probably the reason why I eventually passed. His documentation and diagrams taught me to pay attention to the details. In the end he helped me become who I am today. Treasure the people you work with that take the time to do things right. It may take them a little longer than you’d like but in the end you’ll be happier knowing that they are there to make sure.

Follow My Leader

I spent the past two weeks enjoying the scenic views at the Philmont Scout Ranch with my son and some of his fellow Scouts BSA troop mates. It was very much the kind of vacation that involved a lot of hiking, mountain climbing, and even some inclement weather. We all completely enjoyed ourselves and I learned a lot about hanging bear bags and taking care of blisters. I also learned a lot about leadership by watching the boys in the crew interact with each other.

Storm Warnings

Leadership styles are nothing new to the people that read my blog. I’ve talked about them at length in the past. One thing I noticed when I was on the trek was how different leadership styles can clash and create friction among teenagers. As adults we tend to gloss over delivery and just accept that people are the way they are. When you’re fourteen or fifteen you haven’t quite taken that lesson to heart yet. That means more pushing against styles that don’t work for you.

We have all worked for or with someone that has a very authoritarian style in the past. The kind of people that say, “Do this right now” frequently. It’s a style that works well for things like military units or other places where decisions need to be quick and final. The crew leader exhibited that kind of leadership style to our crew. I sat back and watched how the other boys in the unit handled it.

If you’ve never gotten to watch the Stages of Team Development form in real time you’re missing out on a treat. I won’t go into too much depth here but the important stage happens after we get past the formation and into the Storming phase. This is where motivation and skill sets are low and the interaction between the members is primarily antagonistic. Arguments and defensiveness are more prevalent during storming. It happens every time and frequently occurs again and again as team members interact. It’s important to recognize the barriers that Storming creates and move past them to a place where the team puts the mission before their egos.

Easier said that done when you’re with a group of teenagers. I swear our group never really got past the storming phase for long. The end of the trek saw some friction still among the members. I couldn’t quite put my finger on why that was. After all, we grown ups can put things aside to focus on the mission, right? We can check our egos at the door and hope that we can just get past this next part to make things easier overall.

Style Points

That’s when our lead Crew Advisor pointed out a key piece of the puzzle I’d missed, even after all my time dealing with team development. He said to the crew on the last day, “There are a lot of leaders in this group. That’s why there was so much friction between you all.” It was like a lightbulb going off in my mind. The friction wasn’t the result of leadership styles inasmuch as it was the clash between styles that kids aren’t so good at hiding.

I’m not an authoritarian. I don’t demand people do things. I ask people to do things. Maybe when I want isn’t a request but it is almost always phrased that way. “Please walk the dog” or “Can you get me the hammer from the garage?” are common ways for me to direct my family or my unit. I was raised not to be a demanding person. However, in my house growing up those statements were never questions. I’ve continued that method of leadership as my own family has grown. Dad asks you to do something but it’s not optional.

Where my leadership style clashes is with people who tell you to do something right now. “Get this done” or “You go do this thing over here” wrankle me. Moreover, I get frustrated when I don’t understand the why behind it. I’m happy to help if you just help me understand why it needs to be done. Bear bags need to be hung right away to keep animals from devouring the human food. The dining fly needs to be put up to put things underneath in case of inclement weather. There’s an order to things that makes sense. You need to explain why instead of just giving orders.

As I watched the teenagers in the crew interact with each other I couldn’t understand the defensive nature of the interactions. Some of the crew mates flat out refused to do things because they didn’t get it. They took their time getting necessary tasks done because they felt like they were doing all the work. Until the end of the trip I didn’t understand that the reason for their lack of motivation wasn’t inspired by laziness, but instead by a clash in style.

My son is like me in that he asks people to do things. So when he was ordered to do something he felt the need to push back or express displeasure with the leadership style. It looked defiant because he was trying to communicate that politeness and explanation go a long way toward helping people feel more motivated to pitch in. 

For example, asking someone to help hang the bear bags because there is a storm coming in and they are the most efficient at it is a better explanation than telling them to just do it. Explaining that you want someone to train another person in a job because you excel at it helps the person understand this is more about education than making them do the job over and over again. I’ve mentioned it before when it comes to leaders leaning on the people that get the job done all the time without expressing why. It’s important to help people understand that they have special unique skills that are critical to helping out.

Promoting From Within

Leaders chafe at the styles that don’t match their own. One of the ways to help this process is through delegation. Instead of punishing those that talk back to you make them responsible for leading the group. Let them show off their leadership style to see how it is received. You’re essentially giving that person the power to express themselves to see if their way is better. Depending on your leadership style this may be difficult to do. Authoritarians don’t like letting go of their power. People with no patience are more likely to just do the job themselves instead of letting others learn. However, you need to do it.

Leaders will excel in the right environment. Give someone responsibility and let them accomplish things. Instead of simply giving out tasks let the leaders figure out how to accomplish the goals. I ran a small experiment where I told our crew leader to just take care of his one responsibility and then leave the crew to their own devices. By this point in the trek they knew what needed to be done. If they couldn’t find the motivation to get it done then it was on them and not the leader. Weather forced my hand before I could get the experiment done but when a leader is having issues with those under then chafing at their leadership style they need to empower their group to lead their way to see how effective it can be instead of just falling back on “I’m in charge so you do what I say”.


Tom’s Take

My leadership experience and training has been all about creating artificial situations where people are required to step up to lead. Seeing it happen organically was a new experience for me. Leaders emerge naturally but they don’t all grow at the same rate or in the same way. The insight gained at the end of the trip helped me understand the source of friction over the twelve days were were in the backcountry. I think I’d do things a little differently next time given the opportunity to allow those that needed a different style to come forward and provide their own way of doing things. I’ll be interested to see how those leaders develop as well as how I approach these situations in the future.

VARs See You As Technical Debt

I’ve worked for a Value Added Reseller (VAR) in the past and it was a good run of my career before I started working at Tech Field Day. The market was already changing eight years ago when I got out of the game. With the advent of the pandemic that’s especially true today. Quite a few of my friends say they’re feeling the pressure from their VAR employer to stretch beyond what they’re accustomed to doing or outright being treated in such a way as to be forced out or leaving on their own. They tell me they can’t quite understand why that’s happening. After some thought on the matter I think I know. Because you represent debt they need to retire.

Skill Up

We don’t start our careers knowing everything we need to know to make it. The industry spends a lot of time talking about careers and skill paths and getting your legs under you. Networking people need to learn Cisco or Juniper or whatever configuration language makes the most sense for them. Wireless people need to learn how to do site surveys and configure access points. Server people need to learn operating systems and hypervisors. We start accumulating skills to land jobs to earn money and hopefully learn more important skills to benefit our careers.

Who benefits from that learning though? You certainly do because you gain new ways to further your career. But your VAR gains value as well because they’re selling your skills. The “value added” part is you. When you configure a device or deploy a network or design a system you’re adding value through your skills. That’s what the VAR is charging for. Your skills are their business model. No VAR stays in business just reselling hardware.

Accumulating skills is the name of the game. Those skills lead to new roles and more responsibility. Those new roles lead to more money. Perhaps that means moving on to new companies looking to hire someone that has your particular expertise in an area. That’s a part of the game too, especially for VARs. And that’s where the whole debt mess starts.

Double Down on Debt

Your skills are valuable. They’re also debt. They represent a cost in time, money, and resources. The investment that your VAR makes in you is a calculated return on that debt. If your company primarily deploys Cisco networks then the training you get to install and configure Cisco switches is a return on your VAR being able to hire you out to do that skill. Being able to install and configure Juniper switches isn’t a valuable skill set for them unless they move into a new line of business.

People are no different. We acquire skills that suit us for a time that we may or may not use forever. It’s like riding a bike. We use it a lot when we’re young. We stop using it when we start to drive. We may start again when we need to use a bike for college or for living in a large city or if we pick up cycling or mountain biking as a sport. However, the bike riding skill is always there. It is a sunk cost for us because we acquired it and keep it with us.

For a VAR, your skill is not a sunk cost. It’s a graph of keeping the amount of billable hours you contribute above the line of debt that you create to the company. If you spend 85% of your time installing Cisco switches you are well above the debt line to the company. But if your company stops installing so many switches your value starts to fall as well. It could be that the technology is old and no one is buying it. It could be that companies have shifted the way they do business and need different resources and technology. It could be that a new partnership has created competition inside your organization.

No one wants to the be a last buggy whip manufacturer. VARs thrive on attacking markets that are hot with huge potential for profits. When a skill set becomes a commodity VARs are competing on pricing they can’t always win. That drives them to investigate new markets to offer to the customer base. In order to deliver those new technologies and solutions they need skilled people to install and configure them. The easiest solution is to acquire talent to make that happen. As above, VARs are always willing to pay top dollar to professionals with the specific skill sets they need. Bringing someone in to do that new line of business means they’re producing from Day One and keeping their value above the debt line of their salary.

The other way that VARs compete in these new markets is by training existing professionals on the new technology. Everyone that has ever worked in a VAR knows of the people that get tasked with learning how to deploy new storage systems, new network equipment, and even entirely new solutions that customers are asking for. I know I was that person at my old VAR. If it needed to be learned I was the one to do it first. I jumped in to deploying iSCSI storage, wireless access points, and even VoIP phone systems. Each time I had to spend time learning those new skills and adding them to my existing set. It was a cheaper method in the short term than bringing entirely new talent on board.

Get Out of Town

The friction in the training approach comes when it’s time to value your employees and their skill sets. If I’m getting paid to deploy Cisco switches and now my company wants me to learn how to install Palo Alto firewalls then I’m going to eventually get a raise or a new role to cover this expanded skill set. And rarely, if ever, do employee salaries get adjusted downward to compensate for old skills that are no longer relevant being supplanted by new marketable skills. Suddenly all those technologies I spent so much time learning are technical debt my VAR is paying for.

VARs need to be able to jump into new lines of business in order to survive. And that sometimes means shedding technical debt. If you’re a highly paid employee that earns twice as much as someone that has the specific skill set your VAR needs for a new project then your value to the at this current moment is likely much closer to the negative line of skills versus debt. You may have more experience or more familiarity with the process but that doesn’t translate as well into real value. If it did contractors wouldn’t be as well compensated as they are.

Now your VAR has a choice: keep paying you a lot and investing in their technical debt or bring on someone new that moves more closely with their new lines of business and start the escalator ride all over again. Unless you’re an exceptional employee or you are moved into a management role that usually means you’re let go or encourage to find another role somewhere. Maybe you get lucky and another VAR needs exactly what you offer and they’re willing to pay to get it. No matter what, the VAR is ridding themselves of technical debt. It should be no different than retiring an old laptop or installing new software to do help desk ticketing. But because it’s a person with a life and a family it feels wrong.

Rise Above

Is there an answer to this problem? If there is I don’t think we’ve found it yet. Obviously the solution would be to keep people on staff and pay them what their skill set is worth to the company. But that could entail retraining or readjustment in compensation that people aren’t always willing to do. VARs aren’t going to pay hefty salaries for skills that aren’t making them money. Other VARs may want to pay you for your skills but that’s not always a guarantee, especially if your skill set is extremely specific.

The other possibility is more akin to the contractor system, where you’re only hired for your skills for the period of time that they are needed. In theory that works very well. In practice the challenges of capital asset acquisition and personal benefits make contracting full-time almost as much of a hassle as changing jobs every few years chasing a bigger paycheck or a company that values your skills. There isn’t a clear-cut answer. Part of that reasoning is because the system works just fine the way it is. Why fix it if it’s not broken? It would take a massive shift in IT toward a new paradigm to force the kind of soul searching necessary to change the way VARs handle their staff. Cloud is close. So too is DevOps and programmatic IT. But for the kind of change we’re talking about it’s going to take something even bigger than those two things combined.


Tom’s Take

After reading this I’m sure half of you are scared to death and swear you will never work for a VAR. That’s a bit short-sighted. Remember that they’re a great source of training and experience. Customer networks stay fairly static and only require specific kinds of maintenance from time to time outside of deployments. If you want to hone your skills on a variety of technologies and get very good at troubleshooting then VAR life is absolutely where you need to be. Just remember that you are a resource with a value and a burden. Despite the mantra of being a “family” or other feel-good nonsense you will eventually reach the point of being the uncle that constantly incurs debt for very little return. Every family shuns those kinds of members. Make sure you know your value and how you can contribute. If that’s not possible where you are now then make sure it is wherever you land with whatever skills you need.

Friday Thoughts on Going Back To the Office

EmptyOffice

We’re halfway through 2021 and it’s been going better than last year. Technology seems to be rebounding and we’re seeing companies trying to find ways to get employees to come back into the office. Of course, that is being met head on by the desire to not go back at all and continue to do the job from home that has been done over the past year. Something is going to have to give and I don’t know what that might be.

  • Working from home is comfortable for sure. And the lack of schedule means that people are unknowingly putting in hours beyond what they normally would at the office. At least in the office you can walk away from your desk at the end of the day.
  • Unlimited PTO and flexible work schedules sound great in theory. Except not tracking your PTO hours also means you don’t accrue them. You don’t get paid for time you don’t take off. And a flexible work schedule sounds great in theory but reality says that you’re not likely to get much support if you suddenly decide you want to work noon to 10pm Hawaiian time. Flexible really means “work longer than normal”.
  • The office is filled with tech that you don’t have to maintain. That means when you’re there and the Internet goes down you don’t have to spend your time trying to fix it and keep up with your workload. IT departments have a role to play just like you do. Only their role ends at the office or with confirming that your company-issued equipment is working properly. If it’s your provider or your own personal gear that’s a different story.

It may sound like I’m advocating for you to go back into the office and the nine-to-five grind all over again. That’s not quite the point though. What I’m advocating for is figuring out what’s the best way to get your job done. There are numerous stories in the news about companies asking their workers to return, hearing the refusal, and then making it a mandate to get back to their office to do some part of their job that can’t be done remotely.

Fully Tasked with Partial Credit

The refrain of “I’ve been working remotely for the last year” is a pretty common answer to the call for coming back to the office. But have you been doing 100% of your job remotely? Has every aspect of what you do been able to be completed away from your desk? And if it has, are you doing 100% of the work you were doing in January 2020? I think a lot of the remote work that we’ve seen as of late is a consequence of our jobs needing to be done away from the office but also a reduction in things that have to be done in person. We are able to do our jobs from our house because we’ve reduced or eliminated the things that have to be done face-to-face.

I can say for sure that my role, even having been remote in the past, isn’t the same as it was in early 2020. I used to be on airplanes at least twice a month. I’m finally getting back on one for the first time in over a year next week. The idea of almost foreign to me at this point. And it’s because we knew that there were things that were going to need to change at work due to our inability to do them in person. So while I can say that I can do my job entirely from my house right now it’s only because the part of my job that requires me to get on an airplane all the time hasn’t fully come back into force yet.

This rings even more true for companies that have specific in-person needs. Apple is making news because they’re still pushing to have their employees come back to Cupertino where necessary. That may sound draconian to some until you remember that there is a lot work work on hardware prototypes and development that happens in that building. Those aren’t really things you can do at home. And given how tightly Apple holds that information there’s no way they’re going to allow it to be outside their walls unless absolutely necessary. I don’t know what the right answer is for Apple or for hardware companies in general but the extremes of both sides aren’t likely to get their way entirely.

Compromised Compromises

Several of my friends have remarked that they hate the phrase “new normal” when referring to how society has changed over the past year. The idea that the things we’re doing are going to be permanent parts of our lives from here on out. Yet, for all the grousing about wearing masks or supply shortages or lockdowns when the situation benefits us we’re happy to make it permanent.

The working from home mandates we’ve seen should be examined just like those other measures that aren’t “normal”. It was an emergency measure designed to keep the doors open as long as possible until we could pull through everything going on. Now that it’s time to look at those decisions again people are chafing because this is the one thing they actually like out of the whole pandemic response.

Compromise doesn’t work like that. You don’t get to pick and choose the things you get to have your way on. Instead, you need to figure out what makes the most sense and implement the things that are best for those all around. If that means going back into the office two days a week to do things that can only be accomplished there then maybe that’s what needs to happen. Granted there are still ways to find common ground and negotiate. Maybe you can work from home every other Friday. Or you can adjust your schedule in other ways. But holding out hope that the situation will continue to benefit you as it is right now without any form of further compromise isn’t a likely scenario.


Tom’s Take

I know it sounds a lot like “doom and gloom” for those that want to continue to work from home all the time. As someone that has been doing it for a while I don’t know if I could ever go back into an office full-time. But I also know that when the time comes soon for me to get back to my “office” on an airplane that it’s going to need to happen. Because we can’t get back to the old normal without getting back to the way things were done before. There very well could be a paradigm shift on the horizon for working in offices and how our jobs can be changed to not require in-person work. But I don’t think we’re going to see that happen directly after what we’ve all experienced. That road has more twists and turns yet to come whether it’s headed back to the office or all the way home.

Charting the Course For Aruba

By now you’ve seen the news that longtime CEO of Aruba Keerti Melkote is retiring. He’s decided that his 20-year journey has come to a conclusion and he is stepping down into an advisory role until the end of the HPE fiscal year on October 31, 2021. Leaving along with him are CTO Partha Narasimhan and Chief Architect Pradeep Iyer. It’s a big shift in the way that things will be done going forward for Aruba. There are already plenty of hot takes out there about how this is going to be good or bad for Aruba and for HPE depending on which source you want to read. Because I just couldn’t resist I’m going to take a stab at it too.

Happy Trails To You

Keerti is a great person. He’s smart and capable and has always surrounded himself with good people as well. The HPE acquisition honestly couldn’t have gone any better for him and his team. The term “reverse acquisition” gets used a lot and I think this is one of the few positive examples of it. Aruba became the networking division of HPE. They rebuilt the husk that was HP’s campus networking division and expanded it substantially. They introduced new data center switches and kept up with their leading place in the access point market.

However, even the best people eventually need new challenges. There was always a bit of a looming role on the horizon for Keerti according to many industry analysts. As speculated by Stephen Foskett on this past week’s episode of the Gestalt IT Rundown, Keerti was the odds-on favorite to take over HPE one day. He had the pedigree of running a successful business and he understood how data moving to the cloud was going to be a huge driver for hardware in the future. He even had taken over a combined business unit of networking devices and edge computing renamed Intelligent Edge last year. All signs pointed to him being the one to step up when Antonio Neri eventually moved on.

That Keerti chose to step away now could indicate that he realized the HPE CEO job was not going to break his way. Perhaps the pandemic has sapped some of his desire to continue to run the business. Given that Partha and Pradeep are also choosing to depart as well it could be more of an indicator of internal discussions and not a choice by Keerti to move on of his own accord. I’m not speculating that there is pressure on him. It could just be that this was the best time to make the exit after steering the ship through the rough seas of the pandemic.

Rearranging the Deck Chairs

That brings me to the next interesting place that Aruba finds itself. With Keerti and company off to greener pastures, who steps in to replace them? When I first heard the news of the departure of three very visible parts of Aruba all at once my first thought jumped immediately to David Hughes, the former CEO of Silver Peak.

HPE bought Silver Peak last year and integrated their SD-WAN solutions into Aruba. I was a bit curious about this when it first happened because Aruba had been touting their SD-Branch solution that leveraged ClearPass extensively. To shift gears and adopt Silver Peak as the primary solution for the WAN edge was a shift in thinking. By itself that might have been a minor footnote.

Then a funnier thing happened that gave me pause. I started seeing more and more Silver Peak names popping up at Aruba. That’s something you would expect to see when a company gets acquired. But the people that were hopping into roles elsewhere outside of the WAN side of the house was somewhat shocking. It felt for a while like Silver Peak was taking over a lot of key positions inside of Aruba on the marketing side of the house. Which meant that the team was poised for something bigger in the long run.

When David Hughes was named as the successor to Partha and Pradeep as the CTO and Chief Architect at Aruba it made sense to me. Hughes is good at the technology. He understand the WAN and networking. He doesn’t need to worry about much about the wireless side of the house because Aruba has tons of wireless experts, including Chuck Lukaszewski. Hughes will do a great job integrating the networking and WAN side of the house to embrace the edge mentality that Aruba and HPE have been talking about for the past several months.

So, if David Hughes isn’t running Aruba, who is? That would be Phil Mottram, a veteran of the HPE Communications Technology Group. He has management material written all over him. He’s been an executive at a number of companies and he is going to steer Aruba in the direction that HPE wants it to go. That’s where the real questions are going to start being asked around here. I’m sure there’s probably going to be some kind of a speech by Antonio Neri about how Aruba is a proud part of the HPE family and the culture that has existed at Aruba is going to continue even after the departure of the founder. That’s pretty much the standard discussion you have with everyone after they leave. I’m sure something very similar happened after the Meraki founders left Cisco post-acquisition.

The Sky’s The Limit

What is HPE planning for Aruba? If I were a betting man, I’d say the current trend is going to see Aruba become more integrated into HPE. Not quite on the level of Nimble Storage but nowhere near the practical independence they’ve had for the last few years. We’re seeing that HPE is looking at Aruba as a valuable brand as much as anything else. The moves above in relation to the departure of Keerti make that apparent.

Why would you put a seasoned CEO in the role of Chief Architect? Why would you name a senior Vice President to the role of President of that business unit? And why would the CEO agree to be where he is willingly when that carrot is just out of reach? I would say it’s because David Hughes either realizes or has been told that the role of Chief Architect is going to be much more important in the coming months. That would make a lot of sense if the identity of Aruba begins to be subsumed into HPE proper.

Think about Meraki and Cisco. Meraki has always been a fiercely independent company. You would have been hard pressed for the first year or two to even realize that Cisco was the owner. However, in the past couple of years the walls that separate Cisco and Meraki have started to come down. Meraki is functioning more like a brand inside of Cisco than an independent part of the organization. It’s not a negative thing. In fact, it’s what should happen to successful companies when they get purchased. However, given the independence streak of the past it seems more intriguing than what’s on the surface.

Aruba is going to find itself being pulled in more toward HPE’s orbit. The inclusion of Aruba in the HPE Intelligent Edge business unit says that HPE has big plans for the whole thing. They don’t want to have their customers seeing HPE and Aruba as two separate things. Instead, HPE would love to leverage the customers that Aruba does have today to bring in more HPE opportunities. The synergy between the two is the whole reason for the acquisition in the first place. Why not take advantage of it? Perhaps the departure of the old guard is the impetus for making that change?


Tom’s Take

Aruba isn’t going to go away. It’s not going to be like a storage solution being eaten alive and then disappearing into a nameplate on a rack unit. Aruba has too much value as a brand and a comfortable position in the networking space to be completely eliminated. However, it is going to become more valuable to have the expertise of the Aruba teams creating more synergy inside of HPE and leading efforts to integrate the edge networking and compute solutions together to come out ahead as people shift some of their workloads around to take advantage of all the work that’s been done there. Time will tell if Aruba stays separate enough to be remembered as the titan they’ve been.

When Hardware Drives Software Upgrades

8006701A-85B8-4391-BD36-487B35755676

What’s your favorite version of Microsoft Windows? Is it Windows 10? Maybe it’s Windows XP? Windows 95? Odds are good that you have one version you appreciated more than most. Windows XP, Windows 7, and Windows 10 tend to rank high on the list. Windows ME and Windows 8 seem to rank pretty low. Yet, for all their impressive love and all the users clinging to them we don’t really use anything other than Windows 10 any more.

You might be tempted to say that the OS isn’t supported any longer so there’s no reason to run it. Yet we still drive vehicles that are no longer under warranty. We still buy classic cars that are older than we are and put parts in them to keep them running. Why is software different? What drives us to keep needing to upgrade our programs?

You might be shocked to learn that the most popular reason to upgrade software is, in fact, driven by hardware. It’s not the memory requirements or the fancy new user interface that drives people to move to the new platform. More often than not it’s because a new piece of hardware has requirements that only work on the latest version of the system.

It happened to me once or twice. I can distinctly remember needing to go out and buy a new printer to replace some cheap HP Inkjet I purchased for a project because when I upgraded from Windows XP to Windows 7 the drivers didn’t support the move. Why spend money writing new drivers for a cheap printer when you could just make people go out and buy another new cheap printer? I swear that’s what happened. And, of course, the most expensive the device you purchase the more likely it stays supported, right?

The Lords of COBOL

By now I’m sure you’re all familiar with the little tidbit of information that most of the world’s insurance companies run their databases on ancient mainframes. Why? Well, most of their software still requires COBOL to run. Large organizations don’t like to move to new platforms very often. It wasn’t that long ago that Southwest Airlines moved to a new booking system because the old one only had two days you could schedule flights – Monday through Friday and Sunday. If you scheduled a flight for Monday through Friday you had to have the same flight at the same time every day no matter what. It’s even widely believed that part of the reason that United Airlines merged with Continental was because they wanted to switch to a better booking system.

Why do companies keep these systems around? It should be easy to just migrate off of them, right? Well, reality is that between the sunk cost of operating a mainframe for years and patching the software that you’ve built to operate your business the desire to move to something else isn’t always a driver. After all, if it ain’t broke why fix it? Companies can keep maintaining old systems as long as someone sticks around to keep the lights on. I can remember working with a number of IT professionals over the years that had their jobs mostly because they were the final remaining mainframe wizard that knew how to put the system into maintenance mode or remembered the magical incantations to reboot the old machine after a power failure.

Alas, nothing lasts forever. The current pattern seems to be pretty standard. The old wizards finally decide to retire. They’ve had enough and they’re ready to move to somewhere warm and enjoy not working. The management keeps the lights going because it’s not that hard, right? It would take way too much to rewrite the software or move people to a new platform. Until the day when the system stops working. The day when everything doesn’t come back up. Then it’s panic mode. Was that just the database? What if it’s the actual hardware. Do they still make parts for this? Does anyone even know what this button does? Eventually either the hard decision is made to cut over somehow or an exorbitant amount of money is paid to the former operations people to come back and get things running again long enough to figure out how to keep this from happening again. And if you think you’re going to be able to train a developer to just pick up where the grizzled old wizard left off, good luck. Go find a COBOL training course somewhere. I’ll wait.

Modern Makers Make Mistakes Too

If you think that the modern era of cloud development is any different than writing FORTRAN or COBOL on a mainframe you’ve got a nice set of rose-colored glasses. We’re locking ourselves into the same patterns of thought that brought on the monoliths we’re currently trying to tear down. Every time you enable a feature that only works on one cloud platform or you choose to develop in a hot new language that isn’t fully supported everywhere you’re putting up a barrier that will eventually lead to you making hard choices.

You know what’s different this time, though? You don’t have the luxury of a position where you get to be the wizard that knows how to keep the lights on. As the article above mentions, the race is on to get the COBOL migrated to a modern platform that allows integration with languages like C# and Java. Do you believe that having platforms like that means you’ll get to a point where you can be the last remaining person around that remembers what crazy setup you used to minimize the number of containers an app was using? Or do you think it’s more likely they’ll just fire you, figure out how to integrate your legacy code into a new platform, and go on painting themselves right back into corners?

Hardware is the last true driver to keep people moving along into a place where they are forced to do things the right way. If your hardware doesn’t support something you don’t do it. If you need to ensure that your code is portable you don’t bake in features that require specific hardware or you create a situation where you’re tied to that platform forever. That’s why cloud is a bit scary in my mind. Because you’re agnostic from the hardware. You can do whatever you want without limit.

Want to write software that requires the use of hundreds of processing threads? You can do it because why not? You aren’t limited to just one chip any longer. Want to eat up tons of memory and storage? Go for it. You get to use as much as your credit card can hold. Now the bounds of a programmer’s imagination is no longer limited to physical hardware limitations. If you don’t believe me then ask yourself why there are apps on the App Store today that are bigger then the entire amount of storage that the original iPhone was capable of. Sure, hardware brought us to this point. But ditching the hardware for the magic of the cloud means there isn’t anything holding back those that want to build the biggest, burliest, baddest application they can!


Tom’s Take

Somewhat ironically, I’m not really that worried about the cloud letting people build ugly things to their hearts’ content. Why? Just like terrible movie directors, once you’ve removed their limitations you expose their vulnerabilities and they build something that is unsustainable. Build the biggest app you can. You’ll find out that it collapses under its own weight. Even the promise of the mythical giant virtual machines with 1 TB of RAM haven’t made them materialize. Why? Because it turns out that removing restrictions just enforces them through trial and error. If you have to build small because you can’t get crazy due to hardware you’re held back by external forces. But when you are held back because you tried it that way the last time and you failed by creating an app that takes ten minutes to load you learned your lesson. You get leaner and better and more portable next time. And that’s the kind of driver that makes software and hardware better for us all.