Tag: technology

  • Getting the Enterprise Digital Core in Shape

    Getting the Enterprise Digital Core in Shape

    While enterprises rush to transform their business digitally, most are taking tactical steps rather than building a comprehensive digital core that can be improved over time. Very few are taking a thorough view of their entire technology portfolio and looking for ways to create a cohesive core—their digital core—to provide them the strength and stability to move forward swiftly in their digitization efforts. The enterprise digital core essentially is the vital set of technologies and employee skill sets that enable the organization to deliver its digital services. These services are both consumed by customers and internally by staff and others.

    How do enterprises get their digital core into shape?

    Emphasize Talent Over Technology

    While a strong digital core includes the technological platform, it is also a people-platform. “The heart of digital transformation isn’t technology but the mindset and skill sets of your staff,” said Andy Lin, senior vice-president of strategy and consulting at Nexient. Digitization, he said, means enabling customers to transact and interact with you anytime they want, from anywhere, using any device. The only way to get there is if leadership makes it clear to staff why digitization is crucial; otherwise, they will struggle to adapt, he said.

    If the staff does understand the reasons behind the transformation, they will—instead of just following rules for the sake of rule-following—be much more likely to adopt a digital mindset. They’ll also be more likely to embrace the training and skill set development they’ll need to make the transformation a success, Lin added.

    Scrum.org CEO and product owner Dave West agreed that the digital core starts with the customer. “There needs to be a clear line from the mission and strategy of the business with the outcomes the customer wants,” he said. Teams need to understand clearly how their work helps deliver the organizational mission digitally to the customer, no matter what that mission may be. That means everyone needs to be clear on the nature of the business, or organizational business, as well as what success looks like

    West also advised organizations that seek to improve their digital core to look both inward and outward for support. From within the organization, of course, support should come from leadership, who must set the course and ensure efforts are going in the right direction. “Externally you need to build a network of support from people and organizations that have done it before,” he said.

    Put Cloud at the Core

    Of course, a strong digital core must have a strong technological foundation. In today’s typical enterprise, that may very likely mean more about subtraction than addition. While emerging technologies, such as internet of things (IoT), artificial intelligence (AI)/machine learning (ML) and others are recommended to be integrated within enterprise software, “Many of them are not generally suited to run on legacy IT infrastructure,” said Maxim Ivanov, CEO at enterprise software development firm Aimprosoft. “The digital core relies on intelligent automation scalable platforms that are integrated in the cloud and prepares data for next-generation technologies.”

    Gabriel Salazar, digital solutions manager at systems integrator Enstoa, agreed that building a cloud-based infrastructure goes a long way to improving the digital core. “It’s important, however, not to simply carbon-copy the business processes used prior,” said Salazar. “Look to take advantage of all automation, machine learning and analytics offered by converting and folding them into your updated business process.”

    Finally, if organizations want to have a strong digital core, they are going to have to work to maintain it. “Due to the speed of technology change, getting your digital core in shape is a continuous process. Start by understanding what is preventing you from supporting business goals, what is causing ongoing stability or performance issues and what reduces your time to market,” said Nick Polachek, senior principal of strategy and transformation at Maven Wave Partners.

    To do so, Polanchek recommended building the digital core iteratively while maintaining the focus on delivering business value or resolving current issues. It’s also important, he said, to have a thoughtful future vision for your digital core and ensure that each delivery is at least aligned, if not an improvement, over core technology already in place.

    After all, keeping that digital core in shape is an ongoing process that will require ongoing work and practice.

    — George V. Hulme

  • Tech Pros: Plan for Failure to Breed Success

    Tech Pros: Plan for Failure to Breed Success

    Veteran tech pros will tell you: Failure does not always mean failing at something; it often means failing to do something. Failure can be unpredictable and accidental, but usually, a lack of preparedness causes the most significant incidents. Data centers go down, huge bursts of bot activity generate too many requests for a network to handle and every systems engineer knows that one day—probably sooner rather than later—AWS will go offline. Not preparing for the worst increases the likelihood of the outages, attacks, breaches and downtime that keep tech pros up at night.

    While this spans every aspect of technology, recently there has been a surge in app development failure planning through something increasingly known as “plannable catastrophes.” This pragmatic approach to failure involves considering catastrophes during the application design stage—anticipating disasters on the front end so an app can still perform even under duress. Preparing for catastrophes in this capacity can decrease the amount of time an app is down and give companies the upper hand if an unprepared competitor is experiencing a similar issue simultaneously.

    Plan for Failure

    The first step in planning for failure involves designing a way for processes to fail gracefully—for example, by switching the processes to a degraded service option rather than failing. If one service goes offline, the rest of the application will continue to work. A real-world example of this is enabling users to log in and view documents even if the search process is offline. Another way to plan for failure involves building in request buffering, so the components servicing the requests do not become overloaded. This is designed to prevent possible bottlenecks, especially if there is a spike in requests.

    The second step is to detect failure conditions quickly, so you know when to switch over to the degraded service option. Having full visibility is essential to developing early warning signals for system issues.

    Business Considerations

    Every time an application is down or running slowly, there is a direct impact on the business, either in lost productivity or lost revenue. It’s crucial to bring business context into monitoring performance metrics and to prioritize issues based on business impact, ultimately helping ensure that end users or customers have an optimal experience.

    It’s also key to include endpoint monitoring tools to quickly see if all the functions are online and load times are within range. Monitoring spikes in load or processing times, as well as resource utilization, is also crucial. Together, this will allow you to detect failure conditions quickly, ultimately helping you know when to switch over to the degraded service option—hopefully via automation.

    Creating a Holistic View of a Cloud Environment

    How does planning for failure come to fruition in app development and deployment? The answer lies in creating a holistic view of a cloud environment. Implementing this holistic view from the start of the process involves knowing that an application is going to fail—not if, but when—and planning accordingly. Top best practices include:

    • Shift Left: Integrate operations and monitoring considerations in application design and system architecture, coding, testing and preproduction. This helps both development and operations teams identify issues early, cut down on troubleshooting app issues later and react quickly to keep applications up and running even during spikes in demand or service failures.
    • Adopt an application performance monitoring (APM) tool: Full-stack visibility, from the end user through to the applications and infrastructure, is essential to having the ability to spot the early warning signs of a potential service disruption. To create that view, you should select an APM tool that can monitor the performance of the application holistically and allow you to design meaningful performance metrics and alerts. Implementing a curated collection of easy-to-use tools that seamlessly provide full-stack performance management without the cost or complexity of traditional APM solutions is key.
    • Be pragmatic in app development: Leverage APM tools in the staging or dev environment to measure the effect of variables on performance before the app goes live. Use APM tools to set up baselines at each phase, creating valuable metrics to flag when issues are about to take place and to detect failure before an app goes completely offline. Understanding the app’s baseline activities and response time enables tech pros to identify if the app is performing at the level it was designed. Tech pros can leverage platform capabilities to meet and exceed initial goals.

    Conclusion

    Failure is inevitable. Tech pros must ensure end users continue to have the best possible experience in the application and that business goals and service level agreements (SLAs) are met even amid crises. Preparedness comes in the form of taking preventative measures to help avoid and mitigate failure and having a plan in place to get back online as quickly as possible if preventative measures fail.

    Shifting left, building failure mitigation into the design phase and implementing an APM tool helps create a holistic view of the cloud environment and achieve these goals. Planning and building for failure help tech pros avoid and mitigate potentially detrimental issues, ultimately using failure to breed success.

    — Melanie Achard

  • Digital Transformation Vital for Business Survival

    Digital Transformation Vital for Business Survival

    Businesses are in a fight for their survival, and they know it. Their direct competitors, large and small, are digitizing their businesses. And those businesses that effectively digitize first have much to gain competitively. However, as we’ve reported in “Digital Transformation: Coming from Behind” and other stories, many organizations are experiencing significant challenges when it comes to executing on their digital transformation strategies.

    To get a sense of where companies are in their efforts, managed SD-WAN and cloud services provider Masergy contracted research firm Webtorials to conduct its 2019 Digital Transformation Market Trends Report. The report is based on a survey of large and small companies in 35 countries, and it found that the early digital transformation wins tend to be among customer-facing investments, such as customer service and customer experience.

    Not surprisingly, the report found 78% of respondents believe that their company’s primary industry is rapidly evolving and that digital transformation is necessary to survive the change underway. The benefits respondents cited (ranked in order) were enhanced customer experience and customer relationship management, the ability to maintain competitiveness, enable new ways of doing business, increased productivity, cost savings, increased revenue generation and enhanced product development.

    With the majority of digital transformation efforts failing to meet their established objectives, businesses are clearly facing no shortage of obstacles. According to the Masergy survey, the challenges respondents cited as barriers to a successful digital transformation effort, in order of difficulty, are budget commitment, executive support, in-house skill sets, organizational buy-in and lack of adequate IT infrastructure.

    These findings paralleled findings from other related and recent surveys, including the “State of Digital Transformation” report from research and advisory firm Altimeter. The report found that CIOs (28%) or even CEOs (23%) typically own digital transformation at an organization. That report also found that enterprisewide support is a leading barrier, with many organizations citing the belief that digital transformation is a cost center (28%), elusive ROI (29%) and resistance to change (26%) also are barriers.

    The survey also found that only one-third of respondents believe they can meet their digital transformation goals without help from a solutions provider. This finding parallels other reports. Earlier this year, IDC found that business services related to digital transformation will grow at a healthy 29% annual rate over the next five years.

    Interestingly, the “2019 Digital Transformation Market Trends Report” from IDC found those looking for outside help prefer smaller service providers (58%) rather than larger providers (43%).

    What technologies most support digital transformation? According to this survey, those that help in migrating to cloud or in improving security, as well as data analytics and AI, mobility, collaboration and emerging technology such as virtual reality and IoT.

    These reports show that while businesses are aware of what is at stake for their enterprises, the bad news is they are having a hard time making headway. The good news is that it doesn’t appear too late, just yet, for businesses to get their digital houses in order.

    — George V. Hulme

  • Technology: Isolation in the Age of Automation

    Technology: Isolation in the Age of Automation

    Dependence on technology makes us more independent overall, but it also makes us more isolated. So, what happens if things come to the point where we depend on machines more than we depend on other human beings?

    Earlier this month I attended a presentation about machine learning on mobile phones at Google IO 2019. Right now Google is spending a lot of time and money developing machine learning models and capabilities that operate solely within the mobile device. No connection to the internet is required. It’s a big deal.

    During the presentation, the company showed a video that featured an illiterate woman in India who uses her phone’s text recognition features to read to her. All she needs to do is point the phone’s camera at a recipe or newspaper and the phone converts the text to speech.

    I found the story inspiring as a technologist and as a human being. But it’s not all peaches and cream. At the end of the video, the woman said something that gave me pause. When talking about using the technology to book a train ticket, she said, “I can book it myself. I don’t need anyone’s help.”

    There’s no doubt the phone liberated her, very much in the same way that the light bulb liberated millions of other people in times past, bringing human activity forward beyond the setting sun. Dependence on a particular technology can create greater independence overall. However, I do wonder what happens when things evolve to the point where we depend on machines more than we depend on others, when we no longer need “anyone’s help.”

    To my thinking, human interdependence is the thread that binds the fabric of a society together. The thousands of little interdependencies that make up the human experience have beneficial side effects. To get along, we learn the basic rules of civility. We learn to say “please” and “thank you.” We learn how to wait in line at the DMV. We pick up after our dog. We open the door for others. It’s all part of the implicit contract that makes living with other people possible.

    But, these days it seems we depend more on machines than the kindness of strangers. The fact is, you don’t have to be nice to a machine, even for a self-serving purpose. You can yell at your cell phone. You stick your tongue out at the ATM as it accepts your deposit. Whether you’re nice to it or not doesn’t matter. Your deposit is not going to be processed any faster or slower. Your cell phone isn’t going to disconnect you because you were rude to it.

    Take away these simple rules of civility and strange things happen. It’s interesting that road rage is common, yet sidewalk rage is rare. Maybe wrapping ourselves up in a piece of silicon-powered transportation hardware predisposes us to a hostile attitude when interacting with others in the same situation.

    As I stated earlier, depending on technology makes us more independent in the big picture. But, it also makes us more isolated. Whereas in the past, talking about the weather with a stranger might be a prelude to another conversation that’s more meaningful, today the stranger next to me usually has his ears plugged up listening to his own interests. And, if I really want to know about the weather, I can ask Alexa.

    Modern technology gives me help on demand. I no longer ask a stranger for directions to the train station, I use my phone. It seems as if I need the help of others less during those small, random moments of vulnerability. A machine is but a voice prompt away. And, thus, the thread that binds me to the world at large gets a little bit looser.

    Now don’t get me wrong—isolation is nothing new. Five hundred years ago most people never traveled far from where they were born except on very special occasions. Village life is a case study in group isolation. But, while villages were isolated from the outside world, inside the village it was a different story. The social fabric was dense; the threads were tight. Being shunned by the group was a matter of life and death.

    Today we’re all over the place, literally. But we move in our own domains in which we end up wishing happy birthdays to people we’ve never met but who somehow have meaning to us by way of LinkedIn, Facebook and the plethora of other social platforms brought to life and sustained by something other than human labor.

    Is this such a bad thing? Dunno. I like it that my phone is now my personal stenographer. It helps me think better. But, I’m not sure that Google Assistant will ever be a good best friend. What’s even stranger is that a time might come when I don’t even need one. It will be just me and my mobile device. Then I won’t need anyone’s help, ever.

    — Bob Reselman

  • Digital Transformation Technology and Process: More Similar Than You Think

    Digital Transformation Technology and Process: More Similar Than You Think

    Right around this time of the year, the gym starts to get a little less crowded. Throughout January, it’s packed to the gills with folks freshly motivated by their New Year’s resolutions to get in shape. But by mid-February, the commitment seems to have all but dissipated.

    Why is it so hard to just commit?

    During my last workout, it occurred to me that the set of vacant treadmills next to mine was eerily reminiscent of the state of enterprise DevOps. According to Forrester, 50 percent of digital transformation efforts stalled in 2018. It seems commitment and follow-through are difficult in both personal and professional arenas. Admittedly, adopting and scaling DevOps is no easy feat. While reflecting on what does work, I found some parallels between the transformation process and DevOps itself.

    What Success Looks Like

    According to DORA’s “2018 State of DevOps report,” organizations with the highest level of DevOps execution, as measured by throughput and stability, also achieved the highest level of business performance in terms of profitability, market share and customer satisfaction. In a true case of going fast without breaking things, elite performers realized impressive performance gains:

    • 46 times more frequent deployments (throughput)
    • 2,555 times shorter lead times (throughput)
    • 7 times lower change failure rate (stability)
    • 2,604 times shorter time to recovery (stability)

    These metrics underlie a key tenet of DevOps transformation, which is breaking up large chunks of work into many small pieces.

    Shrinking the Change

    Smaller changes mean getting work out faster, with less risk. They take less time to plan, less effort to execute and are easier to troubleshoot. But, smaller code changes alone aren’t meaningful unless they are coupled with shorter release cycles. In essence, agile without CD doesn’t work.

    Stockpiling a few months worth of agile code iterations into a single monolithic release reintroduces an enormous amount of risk and negates much of the work done to adopt agile software development in the first place. Big queued-up releases often mean someone is stuck working the weekend to iron out all of the things that inevitably go wrong and no one should be stuck with weekend release duty. As Jez Humble put it, “The most important metric for continuous delivery is the number of person hours spent outside of business hours doing releases… and the goal for that is zero.”

    In practice, CD is what brings agile development to fruition; it’s why Gartner finds that 40 percent of IT departments have already invested in CI/CD with a full third planning to invest in 2019. CD is all about small pieces. In the same way agile enables smaller code changes, CD enables smaller releases.

    Not Just Smaller, but Iterative

    At GitLab we use the phrase, “just commit” as a shorthand for continuous delivery and deployment. The idea is that when you have a completely automated CI/CD pipeline, all a developer needs to do is commit code to their branch, and everything else needed to get that code running live in a production-like environment—from containerization to security testing—is automated. Similarly, getting code to production is as easy as merging the feature branch back into trunk with the entire production deployment automated. The message to the developer is, “Just commit your code and let your DevOps tooling do the rest.” This is CD in a nutshell.

    With this type of automation in place, the cost of making a change significantly decreases. This means the cost of getting started is very low, but so is the cost to keep going. Instead of spending a massive effort to map an entire path to your solution, you simply need to figure out your next step and keep iterating. According to GitLab’s “2018 Global Developer Report,” 67 percent of developers report the top challenge to getting work done is unclear direction. By shrinking the change, business leaders will find it easier to set direction for the next step without having to map the entire path. This brings us back to digital transformation.

    Commit to Digital Transformation

    Just like a monolith being decomposed into microservices, the practice of breaking large chunks into small pieces applies to driving digital transformation as well. Like Creighton Abrams said, “When eating an elephant, take one bite at a time.”

    How can enterprises shrink the change?

    For most organizations that achieve successful digital transformation, the initiative usually starts with a single team or innovation unit. This group proves the success for the rest of the organization. It develops that culture, tools and processes that other parts of the organization can then adopt. One example of this principle in practice is the transformation that Chris Hill, Head of Systems Engineering, Infotainment, led at Jaguar Land Rover. When Chris came on board, only three build engineers had the ability to release to production and it took four to six weeks to complete each release. Chris gradually scaled a CI/CD platform, step-by-step over two years, until every team across the organization was able to complete a release in less than 30 minutes. Today, the Jaguar Land Rover completes 50 to 70 deployments per day. This iterative pattern is seen over and over again with enterprise digital transformation. It’s encouraging because it means successful digital transformation can be driven by either executives top-down or engineers bottom-up.

    Keep the Fuel Burning

    According to Argyle, “91 percent of companies have at least started on digital transformation, but only half have created an organization-wide strategy.” This seems to align with Forrester’s metrics on half of the organizations that stall.

    So, how can organizations keep going and avoid the stall out?

    If I can make a confession, I am also one of those New Year’s resolution makers who just started working out in January. How it is that I’m still hitting the gym while others have dropped off? I have found that taking a “DevOps” approach is a key to my success. Instead of broad sweeping changes, I make small incremental improvements one day at a time.

    It turns out the strategy for getting started—“just commit”—is the same strategy to keep going.

    By starting small with a single project and gradually expanding scope in iterative steps, an organization can continue to improve over time at a rapid pace. Small, single-commit code changes coupled with CD increase throughput and stability. In the same way, small, incremental process improvements bring about the greatest success with digital transformation.

    — William Chia

  • Full-Time Employment in the Age of Automation

    Full-Time Employment in the Age of Automation

    Back in 1930, the economist John Maynard Keynes wrote a short essay, “Economic Possibilities for our Grandchildren,” in which he predicted that in a hundred years the 15-hour work week will be commonplace. Keynes made this assertion based on two factors: first, the increase in capital due to extraordinary yields from the compound interest that was made possible by increased foreign (global) investment; second, the growth of technological achievement made necessary by the competitive forces of capitalism and made possible by the availability of excess capital.

    Keynes pointed out that these events are recent in terms of the entirety of human history, taking place over the last 500 years. Before that time, things were stagnant. Gold reserves remained static until the opening of the New World and technology, save for a few episodic breakthroughs, was pretty much unchanged. For example, the way cloth was made during the time of Joan of Arc, around 1400 AD, was not that different than the way it was made when the Roman emperor Hadrian had a wall built across northern England in 100 AD.

    But, the growing availability of money and technology changed everything. By 1920, the more affluent in the population wore factory-manufactured clothing bought in a store. Those of lesser means might still be making clothes at home, but the cloth from which the garment was made came from a factory.

    Mass-market capitalism powered by technological innovation increased human productivity on a scale unique in the human experience. Abundance on a global scale seemed a real possibility within a few generations. According to Keynes,

    “If capital increases, say, 2 percent per annum, the capital equipment of the world will have increased by a half in 20 years, and seven and a half times in a hundred years. Think of this in terms of material things—houses, transport, and the like.”

    Yet, today most people work 40 hours a week, if not more. Considering that Keynes was essentially a quant who lived and breathed data, how could he get it so wrong?

    My thinking is not so much that Keynes got it wrong, but that we’re having a hard time accepting that he might have gotten it right.

    Allow me to elaborate.

    The Facade of Productivity

    I have a theory: For the average contributor-employee in a medium- to large-size corporation (with 500 employees and more), of all the tasks he or she performs during a 40-hour week, only about half—20 hours’ worth—actually add value to the enterprise. The rest is organizational overhead. Thus, there is a good argument to be made that when you do the math, what we can call real full-time employment is closer to Keynes’s prediction of the 15-hour work week than not. The remaining time, which I call “organizational overhead,” is really just a facade of productivity.

    This theory occurred to me a while back, when I was sitting in a sprint planning meeting observing a project manager and tech-leads do task assignments. The first thing the project manager did was to determine how much time each member of the project team had available to work on the project’s tasks. The agreed-upon number was 20 hours a week.

    The 20-hours a week number struck me as strange. All members of the project team were completely dedicated to the project. They had no side work. The project was their one and only focus. What were they doing with the other 20 hours?

    I asked the project manager and he answered, “Well, they have to do things like answer emails, go to meetings and sometimes there’s some firefighting to be done.”

    Oh.

    The Amazing Ability to Absorb the Cost of Organizational Overhead

    I wish I could say that the project manager’s response was unique. But, in my experience, it’s not. I’ve been in more than one company in which meetings, email and firefighting occupy at least half of a full-time employee’s work week. And, I’ve got to tell you that, except in the rarest instance of mission-critical firefighting, most of these situations have marginal productive value.

    Granted, my theory is based on experiences that are anecdotal. The actual numbers might prove me wrong. Obviously, a thorough, quantitative study is needed. Still, whether it’s five, 10, 20 or even 35 hours a week, what’s amazing is not that employees spend a lot of time in activities that have questionable productive value, but rather, that businesses can actually operate profitably despite these ongoing time-sinks. Why? Because of automation. Machines and software are allowing people to do more work in less time—and it’s not only confined to IT.

    The Dirty Little Secret of Working on an Assembly Line

    Doubling up has always been the dirty little secret of automotive factory work. Ben Hamper revealed the details of technique in his 1986 book, “Rivethead: Tales from the Assembly Line.” Here’s how it works: Imagine that you and I work in a GM plant and do jobs at the same location on an assembly line—say, putting headlights and taillights in a car. Your job is to put in the headlights; my job is to put in the taillights. One day I notice that I can probably put the headlights and taillights in a car in the same amount of time it takes two of us to do the tasks separately. So, I propose a deal to you: I’ll do your job and my job for four hours a day in exchange for you doing the same for me. This way we can both work half time for full-time pay. We might have to pay the line foreman a small bribe to look the other way, but what the heck? The benefits are obvious, so we do it. Win-win, as the saying goes.

    How can we pull this off? Simple: as stated earlier, automation.

    Without the technology of the assembly line, we just couldn’t double up. The car needs to be brought to us for us to increase productivity to the point where one person can do the work of two. The automation of the assembly line effectively reduced our work week while maintaining our productivity, just as Keynes predicted.

    As you can see, the 15-hour work week is quite possible—and, in many cases, quite real. It’s just that the facade of productivity, which exists in larger companies, hides its existence. But, what about the smaller companies such as construction companies, law firms, small manufacturers, dental offices and software startups that employ fewer than 100 people? These types of companies cannot afford a lot of non-productive activity. How do these companies get to the 15-hour work week? Is it possible?

    My answer is yes, but the world that will need to exist to make the 15-hour work week possible will look dramatically different than the one we have today. What will that world look like? Allow me to illustrate using my neighborhood cafe, the C&M, as an example.

    The Real Implications of the 15-Hour Work Week

    My favorite neighborhood cafe is the C&M. It’s a hangout sort of place with good food, good coffee and Wi-Fi. The C&M is usually staffed by two employees during its business hours—7 a.m. to 5 p.m., seven days a week. Between them, they take orders as well as make the food and deliver it to the tables.

    Let’s do the math. Let’s figure that the actual working day at the C&M is 12 hours—10 hours of operation time and two hours of setup and cleanup. That comes out to 84 hours a week. Thus, excluding the owners’ time, the number of employee hours needed to run the C&M is 168. (two employees at 84 hours a week.) This comes out to around four people required to staff the business using the current 40-hour work week model, again excluding the owner’s time.

    Now, let’s say the business is quite profitable and the owner can afford to pay employees $20 an hour, plus health insurance. Adding in payroll tax and workman’s compensation (more than $5 an hour) plus the cost of health insurance ($400 a month, for illustration purposes), the weekly cost of each employee working 40 hours is $1,100, which translates into a total weekly labor cost for the C&M of $4,400.

    So far, so good.

    This time, let’s interpret the C&M labor situation in terms of the 15-hour work week. To cover the 168 hours per week that the C&M is operational, at a 15-hour work week per employee, the C&M needs to employee 11 people—actually, it’s 11.2 employees, but I rounded down. So, under Keynes prediction, if each employee is entitled to the established full-time compensation of $1,100 as calculated earlier, the weekly payroll for the C&M goes from $4,400 a week to $12,100—an almost three times increase, which is not an affordable number. Even though the number of employees has gone up, the odds are that the actual sales will remain the same. Instead of having to employ four people producing $14,000 a week in sales—$2,000 a day over seven days, again for illustration purposes—now the owner of the C&M will be employing 11 people to produce the same amount. Bankruptcy is imminent.

    Clearly, the C&M cannot tolerate 11 people working 15 hours a week for a full-time wage under current conditions. So much for the 15-hour work week. Well, not so fast. Let’s reimagine the scenario from a different angle: Suppose that the number of employees stays at four, but instead of working 40 hours a week, each employee works 15. What could we add to the mix to make this scenario possible? Give up? OK, I’ll tell you: robots.

    Imagine that instead of having two people on hand to set up the cafe, take orders, make the food, bring it over to tables, bus the table and then clean up at the end of the day, we had one person on hand to do what we’ll call human essential work. All the other work gets done by robots. Then, the typical interaction looks like this: Customers enter orders directly into an iPad, the robotic coffee maker gets the order and makes the double espresso, a robot in the kitchen makes the food, with the intermittent help of a human when necessary, and a robot delivers the food to the table. The one human on hand interacts with customers and picks up the slack work the robot can’t do. You can think of the scenario as the restaurant equivalent of a driverless Uber ride.

    Is such a world possible? Yes. In fact, it’s happening as you read this article. There’s already a chain of waiterless sushi restaurants in Japan. As the technology drops in price, more restaurants will make the transition.

    The 15-hour work week could indeed become a real possibility provided that two conditions exist: affordable robotic technology with a high degree of manual dexterity is available, and the employer is willing to pay the higher wages necessary to support the model.

    In the past, workers such as Ben Hamper used their ingenuity to take advantage of the reduction in labor that automation made possible. Sadly, such efforts were clandestine and deceitful. All that GM needed to do to realize a better return on labor was to speed up the assembly line. Yet, when you think about it, back then GM wasn’t doing that badly when Hamper was doubling up. 1984 was a record-setting year in sales, despite his shenanigans. Speeding up the line would undoubtedly increase GM’s bottom line. But, would it double Hamper’s take home? Probably not. (Author’s Note:  GM’s sales dropped 26 percent in 1986, but profits were still a healthy $1.06 billion.)

    So here are two questions to contemplate: As companies, large and small, adopt robotics to increase productivity, will they indeed share the benefits of the increased productivity with the average worker so he or she can enjoy a 15-hour work week? And then, should the 15-hour work week indeed become standard, what will the average person do with all this newfound leisure? As the saying goes, idle hands make fretful minds. According to Keynes:

    “Yet there is no country and no people, I think, who can look forward to the age of leisure and of abundance without a dread. For we have been trained too long to strive and not to enjoy. It is a fearful problem for the ordinary person, with no special talents, to occupy himself, especially if he no longer has roots in the soil or in custom or in the beloved conventions of a traditional society.”

    For those of you that think about such things, I will leave up to you to answer these questions. As for me, I can’t wait for the robots to take over so I can go back to my studies, full-time.

    — Bob Reselman

  • Reducing Poverty in the Age of Automation

    Reducing Poverty in the Age of Automation

    In 1966, more than half of the people in the world lived in extreme poverty. I don’t mean public housing, food stamps, subsidized school lunch, free health clinic poverty. I mean the type of poverty in which there’s no electricity, no running water, no toilets and open sewers, and most children never see a doctor or the inside of a classroom. Back then, people living in extreme poverty had a daily diet of gruel; not rice and beans, mind you, but mushy, flavorless, boring gruel. Violence was rampant. Infant mortality was high and living to 65 was more the exception than the rule.

    While it’s true that there were pockets of prosperity to be found in the Third World, for most people, if you didn’t live in Australia, Japan, North America or Europe, the odds were your life was not that different from a peasant living in the Middle Ages, except that maybe you had access to a TV or radio in the village square.

    Cheap Technology Contributes to Declining Rates of Poverty

    But things changed. In 1997, the number of those living in extreme poverty dropped to 42 percent of the people in China and India. By 2017, the number dropped again, this time to an amazing 12 percent in India and .07 percent in China. Now, this doesn’t mean that everybody in India and China rode around in Toyota Camrys and spent their evenings gazing at a 52-inch high-def TV, but it does mean that just about everybody went to school, saw a doctor and had some choice in what they ate for dinner. It might not seem like a lot, but when you consider that their great grandmothers could barely read a newspaper, it’s a big deal.

    This progress didn’t happen by magic, and there’s a good argument to be made that it didn’t happen because of politics. My opinion is that it’s due in good part to the proliferation of cheap technology brought about by automation.

    The Toothbrush as an Agent of Change

    Small pieces of cheap technology can make a big difference. Take the toothbrush, for example. Not that long ago, a personal toothbrush was a luxury item for many. Today there are machines that make them automatically by the dozens, for pennies in material cost. Anybody can buy one and those who can’t many times can get one for free. Think what it must be like for a 7-year-old child in a classroom trying to learn how to read while in the throes of dental pain. There wouldn’t be a lot of learning happening.

    Studies have shown that a leading indicator of good health in the long term is the practice of good dental hygiene on a daily basis. Giving a child a toothbrush and some toothpaste early in life makes a big difference. Children who brush their teeth regularly fare better. A toothbrush might seem like a trivial consumer good, but it is actually a high-impact technology that has lifted many people out of poverty.

    Faster Credit Reporting Means Less Poverty

    Another example of a small piece of automation that’s improved the lives of billions is credit reporting. Thirty years ago it took a few days to get the credit rating of a company, and getting the credit rating of a sovereign state could take longer. Today, getting a credit report takes seconds. Automated credit reporting accelerates financing, which not only makes it easier for a consumer to get a home mortgage or car loan, but also for sovereign states such as India to get large-scale, industrial goods such as bulldozers. More bulldozers translates into more roads; more roads lead to more commerce and more commerce leads to prosperity for more people. It’s a pattern that’s difficult to ignore. Just take a look at the economic growth that accompanied the expansion of the U.S. interstate highway system in the last century. In this century, the same growth pattern is underway as China grows its One Belt, One Road (OBOR) transportation infrastructure on a global scale.

    The Cellphone: A Tool for Prosperity on a Global Scale

    Which brings us to the cellphone. The first mobile phone cost $4,000. Today, you can buy a prepaid, throwaway one with service for around $50. Given the technical infrastructures required to build the phone and networking infrastructure necessary to provide service, selling a fully functional cellphone profitably at $50 is a near miracle. And, its impact goes way beyond a simple, “What time will you be home for dinner?” conversation. There’s a big difference between living in poverty and living in poverty yet having a cellphone. A cellphone puts a person on the grid even when living in a hut in a remote village in Niger. Having a cellphone means being able to solicit paying work. It means having access to simple bank services. It means being able to get medical care in an emergency. And, a cellphone can connect users with online learning resources that can enhance the educational experience for those living in parts of the world where access to secondary education is rare. It’s no wonder the Gates Foundation is focusing on programs that use cellphone technology to address issues in poverty stricken areas.

    Not only has cheap technology reduced the cost of cellphones to nearly free, it also has reduced the cost of dental crowns through 3D printing technology and international trade through automated navigation systems for ocean-going vessels. Cheap technology also has brought about free online college courses and built-in writing assistants for email clients that have had the surprising effect of giving people better command of the written word.

    The Fall of Global Death and Destruction

    Our technological achievements allow us to grow more food, educate more people and reduce the level of violence to an all-time low. Remember, 20 million Russians were killed in World War II. That’s 5 million people a year over from the beginning of hostilities in June of 1941 until the war’s end in August of 1945. We’ve not seen slaughter in such numbers since that time. Yet, news of today’s conflicts is broadcasted on a global scale, so it can seem as though millions are dying everywhere. But the actual number of people killed in armed conflicts today comes nowhere close to the number casualties that were the result of the world wars of the last century.

    As the Numbers Go Down, the Risks Become Greater

    Things are getting better for more people and we technologists have been significant contributors to these improvements. Yet, new risks are on the horizon that could stifle the upward trends. One of the biggest potential dangers is a worldwide pandemic. While cheap air travel has removed the barriers of international travel for more people, it also has made it easier for a highly contagious disease such as Ebola to spread faster.

    And then there’s always the risk of nuclear catastrophe. The number of nuclear weapons has decreased, but technology has made possible nuclear devices that are the size of a suitcase. Whereas it takes the resources of a sophisticated sovereign state to create and deliver missiles capable of a nuclear strike across continents, all that is required for a non-state belligerent to deliver a nuclear blow is a small device hidden in the trunk of a car driven across an unguarded frontier. It’s a remote possibility but a possibility nonetheless, and one that can have a catastrophic outcome of unimaginable dimensions. Fortunately, for better and worse, we in technology have created planetary surveillance systems that make it possible to guard against such an occurrence.

    Considering the Big Picture

    Technology grows in complexity every year, particularly for those of us in DevOps. The rate of innovation can be overwhelming. We’ve got to know more to do more. As such, many of us give most of our attention to the details that make the technology work. Sometimes we lose sight of the big picture. But, here’s something to consider: As weird as it may sound given current perceptions, there’s a good argument to be made that, given the increasing rate of technological innovation and the reduced costs of mainstream technology produced by such innovation, we might eradicate extreme poverty in our lifetime, if not the lifetime of our children. In the past such thinking was considered grandiose. But, as the $50 cellphone demonstrates, it’s a goal we can look forward to achieving.

    Authors note: The source of the data on the reduced rates of poverty worldwide described in the opening of this article comes from the book, “Factfulness” (pages 52-53) by Hans Rosling , Anna Rosling Rönnlund and Ola Rosling.

    — Bob Reselman

  • 4 Questions to Ask a Web Developer During an Interview

    4 Questions to Ask a Web Developer During an Interview

    Web development is a fragile process. You need talented web developers to make truly beautiful sites with seamless user experiences and fast loading speeds. Without experienced web developers, creating a website that has both form and function is exceedingly difficult.

    Web developers have a great deal of responsibility. They understand design and they understand how to implement that design using programming languages, tools and frameworks. How do they piece all of these skills together? How do you assess whether they have these skills?

    There’s no formula for the interview process that guarantees great hiring decisions. There are a few questions you should consider appending to yours, however, as they can help you get to know the web developer a little better.

    Here are four questions to include in your interview with a qualified web developer:

    1. What programming languages, tools and frameworks are you most familiar with?

    Web developers are usually proficient in a number of programming languages and are adept at wielding frameworks. They must have an in-depth knowledge of HTML, CSS and web scripting languages such as JavaScript. If the role you’re hiring for includes back-end programming, they also will need to know how to program databases by using PHP or even Python.

    Content management systems such as WordPress can also be extremely helpful for web developers. Bootstrap and frameworks also may be helpful when building web pages.

    You’ll want to ask more about the technologies, programming languages and frameworks they like using. Don’t limit your questions to strictly the technical requirements of the role. Assess the developer’s passion and knowledge.

    1. How do you stay relevant as a web developer?

    Technology is constantly evolving. Web developers have to have strategies to stay up to date on the latest updates, frameworks and trends. There’s no wrong way to keep up self-education. A potential web developer candidate might cite online courses as a way to stay skilled and knowledgeable.

    Web developer meetups, professional web development classes and sites such as StackOverflow and GitHub can help developers stay informed and in conversation with other developers.

    1. What are some mistakes you’ve made in the past as a web developer? How did you react to those mistakes?

    Web development is a complex process. There are lots of little things that can go wrong during development. It’s not uncommon to make mistakes even as an experienced web developer. However, it’s still important to assess how a candidate responds to tricky situations.

    Do they show themselves compassion when they make a simple mistake? Do they create actionable plans to remedy mistakes when they appear? Are they resilient or easily defeated? Are they prone to blaming others or do they take responsibility for their actions?

    It’s important to know how a candidate will respond to stress especially if you expect your projects to be lengthy or complicated.

    1. What would you like your role to be?

    It’s easier to get to know a candidate if you know the activities they like to perform. Are they interested in leading a team? Do they enjoy helping design wireframes with the design team? Do they take great pleasure in optimizing back-end processes?

    Ask the web developer candidate about their own likes and how they can best fulfill their duties as a member of your company’s team. You’ll find out a great deal about their personality, preference, and work style with questions that probe into their own likes, dislikes, and dreams.

    Conclusion

    Great web developers are rare. Even though it’s hard to attract the top web developers on the market, it’s not impossible. By asking the right questions, you’ll capture the imagination of the best web developers and, hopefully, gain some insight into their own creative and technical processes.

    Delve into a few technical aspects of the job, gauging their familiarity with popular programming languages and tools. Make it a point to ask web developers about past projects and performances. See how they self-assess and gauge their capacity for compassion, collaboration and resiliency. Continuing education is also important for web developers as trends often change.

    Be sure to also delve into their personal preferences and opinions as this will help you better understand how they work and if they are the right fit for your organization.

    — Greg Robinson

  • Roadblocks to Successful DevOps Often Human, Not Technical

    Roadblocks to Successful DevOps Often Human, Not Technical

    Usually, when people talk about DevOps, they focus on the technical aspects. However, in my experience we need to highlight what lies behind technology: the people. To effectively implement DevOps, we have to understand that many obstacles are not technical, but human.

    In working with various organizations in their DevOps journeys, I have seen six main roadblocks to a successful DevOps implementation:

    1. We mistakenly blame technical obsolescence: Tech teams should avoid justifying slow processes and lengthy deployments just because of the existence of old systems. To do the best with current systems, analyze your workflow and decide whether the problem is less a matter of technical tools, but one of attitude and organization.
    2. We don´t cooperate: DevOps doesn’t work unless teams can work together. There are three steps to building collaborative teams. First, work hard. Your good work speaks for you; it gains you the respect and cooperation of your colleagues. Second, highlight the contributions of others. Offering recognition shows that each member of these diversified teams is important. Finally, learn how other teams are being evaluated so that you better understand their behavior and can work with them in achieving real cooperation.
    3. Our egos get in the way: Ego leads us to believe that our approach and knowledge apply to every problem and that we can simply solve these issues. It prevents empathy and the ability to properly help to those who come from a different context or background. In DevOps teams where people come together from different perspectives and backgrounds, this is particularly important. So please check your ego at the door.
    4. We are unwilling to leave our comfort zone or the status quo: DevOps is about speeding up processes and providing new ways to work. As a result, DevOps teams should question traditional methods and understand that some rules no longer apply in the digital world.
    5. There is a lack of leadership: DevOps teams succeed under real leadership. Real leaders give visibility to everyone and understand that anyone can offer critical contributions, even when least expected.
    6. We suffer from cognitive bias: Cognitive bias comes from our background, our personal experiences and our careers. However, we shouldn’t let this condition us. It is essential to move forward and understand that our experiences and knowledge do not apply to every context. DevOps teams must be aware of cognitive biases to build a proper solution for problems that may arise.

    These six human aspects can often form obstacles to DevOps implementation. To help overcome these challenges, I typically recommend three broad strategies to organizations:

    • Technology is a means but not an end. It is important to understand that technology is what helps us solve problems, but it’s not the solution in and of itself.
    • Understand the problem and find balance. Avoid over-engineering; you do not need to prove how much you know about technology in general, you need to find the proper solution.
    • Be humble and curious. Technology is never static. There is always something new to learn. In the field of DevOps, it’s critical to constantly investigate and renew ideas.

    A successful implementation of DevOps is not only about automation. It is also about people who make decisions and use tools. However, for many enterprises, transitioning to DevOps represents a fundamental shift in how individuals and teams will have typically worked in the past. This is why I encourage DevOps teams to evaluate their workflow and be aware of aspects such as ego or biases, as they do affect performance. Handling these situations might require professional assistance. I suggest working closely with human resource professionals or turning to business psychologists to understand these human aspects. In turn, this will enable your DevOps teams to walk toward success.

    — Ernesto Cardenas

  • DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    Those of you who have been reading devopsy.kinsta.cloud for a few years are familiar with the RoelBob cartoons, which have a prominent spot on the home page. RoelBob’s creator, Bob Reselman, is also a technologist and creator of other forms of media. Lately, he’s been writing a series of articles about the impact of automation on society as a whole—not just DevOps.

    Bob is a really smart guy and a great interview, as well. Even if you don’t agree with this thoughts on automation, it’s worth giving what he says a listen.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Got a really great DevOps Chat for y’all today. I’m joined by a good friend of mine, a frequent contributor, one of the team at devopsy.kinsta.cloud—none other than Bob Reselman, creator of the RoelBob cartoons, Bright Ideas TV, the creative force and brains behind Shimmy Tunes, as well as a writer in his own right, not only at devopsy.kinsta.cloud, but at a lot of the leading tech companies out there today.

    So, Bob—welcome!

    Bob Reselman: Oh, thanks for having me, Alan.

    Shimel: You know, I hope I didn’t embarrass you at the log-on, but you know, you’re something of a Renaissance man, right?

    Reselman: [Laughter] Right.

    Shimel: I was reading a little bit of your life history, your life story, Bob.

    Reselman: Oh, yeah. Well, I came to tech late. I came to tech in my early 30s, and the reason I got into it is because somebody told me that I could actually compose music on a computer.

    Shimel: [Laughter]

    Reselman: No, it sounds funny, but if you’re a composer—and I don’t mean—

    Shimel: Like in the MIDI days. I hear you, dude. I know people like that.

    Reselman: Yeah, back in the MIDI days, and you know, if you had a string quartet or even something larger, like an octet, to actually hear that going on, to hear it was very hard. You had to go out and either hire a quartet to play or just be really good at imagining, or be able to sit at a piano and be able to pay some stuff. And I’m not the world’s best pianist, so this medium, this technology really opened up a world to me.

    And then one day I’m sitting around and I’m starting to play with this, and I’m writing it, you know, my string quartet and stuff. I said, “You know, I think I could probably do something with programming.” And so, I did. I actually, I learned to program, and I’m one of those people that came in through the back door. Eventually, I ended up at Gateway, at that time, Gateway 2000, and I—

    Shimel: [Cross talk] cows, we remember it.

    Reselman: Yeah, the cows, yeah. I moved from Boston, Massachusetts to Sioux City, Iowa, which was a complete cultural transformation for me. But every day, I went into the future, this big, big building where we were making computers. I learned a lot, and we can talk about that, too.

    And at Gateway, I was really doing a lot of stuff I shouldn’t have been doing, but I did ‘em, anyway. And I mean that, I just, I sort of had to battle my way into technology. And they were very supportive, and I just learned a lot about some real, hardcore tech, working for that company, and for that, I’m ever grateful.

    And so, that was around ’98. Around 2000, I decided to move on, and I had started doing Big 6 consulting, went into Big 6 consulting. I went into New York and I worked in the financial industry for a while, and then I got good at it. Along the way, back around 1995, I published my first book about DB programming, and Wygant has been very good to me. I still get those royalty checks every month. I can’t complain. That’s how I got here—that’s how I got here, you know? And here I am today.

    Shimel: So, Bob, over the last couple years—I mean, look, we’ve been doing, so, devopsy.kinsta.cloud has been around four years. You’ve probably been doing writing and RoelBob stuff for, what, three years, two and a half years—something like that?

    Reselman: I think three. We’ve been together for a while, Alan. It’s been, you know, the “Casablanca” of technology, what can I say? We’re on the runway, walking into the fog, right? [Laughter]

    Shimel: [Laughter] Round up the usual suspects.

    Reselman: There are no usual suspects. [Laughter]

    Shimel: But Bob, you know, certainly with the advent of DevOps and a heavy emphasis on automation, but also, it’s not all DevOps, it’s the world we live in, as you’re fond of saying.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: You know, automation and the specter of increased automation over the—you know, not only near term, but long term—is really, it’s a scary thing. It’s scary for me as a parent with teenaged boys in terms of what are they gonna do, but it’s scary for a lot of people, people in the workforce today. And it’s something that you have really given a lot of thought to, you’ve written extensively about it, and that’s what I wanna talk to you about today.

    Reselman: Mm-hmm. Well, I’m happy you do, because I do think it’s important, and I think it’s going to have a growing impact. A lot of people—within technology, we can sort of ________. We’re in the middle of it, and we’re pretty adept at adapting—I don’t know if that’s a real term, but we pick up stuff pretty quickly, and we’re good at getting new stuff onto our fingers very quickly.

    But there’s a whole segment of the culture that has problems with it, to be honest. And, you know, let me be direct. Let me be direct, here. My father, he was a cab driver. He was a cab driver, and when I look at what Uber and Lyft are doing to the cab industry in New York City, it’s pretty amazing. I mean, his first medallion, I think, cost him—I’m making these up, I don’t have the actual data, but I think he paid $250,000.00 for his first medallion. And back then, that was a lot of money. But there were only a set amount of taxicabs on the street, and so, there was a high volume, it was a good investment. Today, because of the ride sharing, share services the value of medallions is dropping dramatically. And that’s just one impact of automation.

    Uber and Lyft could not exist without, I wanna say, two fundamental technologies coming on. First of all, credit cards. The other one is GPS, and the third is cell phones. And you mix all three of those together, and anybody can really be a driver. Why? Because you can pick up qualified customers and bill them without having to worry about being paid. GPS will pretty much tell you where to go, and cell phones provide the mapping technology to get there—all of it highly automated.

    Now, what’s interesting to me is that I wonder about the actual Uber and Lyft drivers now as that automation extends. For example, I take Lyft. I take Lyft all the time, and I’m more of a ride sharer than I am a car owner. And I’m sitting in the back of a car, and I had to go to an appointment, and I started reading a book. And I noticed that we were going in the wrong direction. We were going in the wrong direction. I said to the driver, I said, “You know, we really are going in the wrong direction,” and her response was, “Well, this is where the map is telling me to go.”

    Now, what is relevant here is, how far are we really—what is the purpose of that driver, other than to be an interpreter of map data and to manipulate the technology accordingly? And that’s not that far from robotics, and people—

    Shimel: No, it’s not. And actually, I mean, Bob, Uber and Lyft’s end game is to go autonomous, obviously, right?

    Reselman: Right.

    Shimel: And take the driver out of it altogether. But the interesting thing, I’ve had, specifically around Uber and Lyft, but they’re really poster childs for this, right?

    Reselman: Mm-hmm.

    Shimel: When we start thinking about the future of autonomous vehicles, we start thinking about, what really is—what is the disruption in Uber? You mentioned three key technologies, but is Uber really a technology disruption company, or is Uber a company that, what it disrupted was, by taking advantage of all of the excess vehicles and time that drivers have and putting that to good use? And so, was that the true disruption there, or was it the technology that was the disruption, and part and parcel with that technology is the automation?

    Reselman: Right. I think the disruption—it’s the aggregation of the technology which is the disruptor. Now, what is being disrupted? I think there’s a fundamental social disruption going on. The rules of existing as an employee or a wage earner or a value creator in society is changing. And Uber’s talent in terms of transportation—because it’s everywhere, you see everybody getting into those Uber cars. But that’s really inconsequential compared to the larger impacts of transportation.

    So, for example, container shipping is, Swedes Burkett just released a thorough—and again, people can write me and I’ll give them the exact data, because I don’t have it in front of me—but I believe it’s called the Burkett, and that’s a large container ship that’s completely robotic. So, imagine how much containers get shipped on the open seas that have crews. Now, those crews will go away.

    The same as with trucking. Trucking is really low hanging fruit. There are 3,000,000 truck drivers, and Uber is active in the trucking—automated trucking industry. So, they’re looking to automate that, and that’s gonna have a disruption.

    I wrote—the last article I wrote for you all was called “Coming Apart in the Age of Automation,” and the unintended impact here is that we really are creating a bifurcated society in which one class has, can master the technology or becomes the merit class, and the other class is just sort of hanging on. And it’s a sad thing to say, but it is true. And, as we look around current events, we can see that more and more.

    Now, the good news here is that we’re in a—we are in a good position. And what I mean by that is that, if we go back and we look at the history of technology, particularly around the advent of mass production in consumer technology, which is really the automobile. The automobile really was a game changer, because it was intended to be a consumer product once Henry Ford figured out how to do the assembly part. And because it became a consumer product, it really lifted the whole middle class. It became—if you were coming off a farm in Georgia, you could go to Detroit, and without having to learn a whole lot of new skills, become a wage earner in a factory.

    That’s good. Nobody really understood the impact of the internal combustion engine back in 1900 or 1910, that in 100 years, this would have a significant impact. And what I hope we’ve learned along the way is that technology does have an impact, along with sociological and economic. And we can start planning for that accordingly. Sadly, what I’m not hearing is that planning. People hear—the argument is, technology, yes, will always displace people. There are no more people picking up the horse dung on the streets of New York. Those people went to work in factories, et cetera, et cetera. In other words, technology destroys jobs, but it creates more jobs.

    But we’re not hearing any sort of ancillary planning of what the downside might look like, and if there is a downside—which there might very well be—how we’re going to address that.

    Shimel: Yep. I—you know, Bob, maybe I’m cynical in my old age. [Laughter] I—unfortunately, planning is not our long suit, right? We live in a financial world where we live quarter to quarter, week by week, you know? A bad quarter can cost a CEO their job and lose trillions or billions—not trillions, but billions of dollars of market capitalization.

    Reselman: Mm-hmm.

    Shimel: The fact of the matter is, if you believe the media, most people in our age group, Bob, have not put away enough money for retirement.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: We don’t believe in science or truth, [Laughter] and so we can’t even plan around what to do about climate change. Why should this be any different?

    Reselman: Well, I don’t know if I agree with your assessment completely.

    Shimel: Okay.

    Reselman: Because I just got through reading a book by Harari about, it’s an assessment of current conditions and future. And people forget that famine and people dying of starvation even 50 to 60 years ago was a common day event. A lot of people in China starved to death. That really did happen. People in Ireland, in 1840 when the potato famine came along, they starved to death. You didn’t have enough food, and you died. Death due to starvation is still around, but it’s not commonplace—nowhere near the condition that it used to be.

    The other thing is, when we look at warfare—yes, there are wars going on and there are mutual wars, but there hasn’t been a war on the scale of World War II since World War II. So, there’s stuff going on that sorta gets hidden behind all the—what would we say—the fascination with the bad stuff.

    The other thing to think about in terms of us as technologists is that planning is still part of the industrial fabric. What do I mean by that? It takes five years to design and manufacture a car. I learned this when I worked at Edmonds. Pretty much, if you start looking at model years, the big model changes are in the fifth year. Pretty much, if you came out with a Car A—in year one, you’ll have A, then year two, what used to be options become standard and then more options become standard. And then, by year five, you have enough research in place and enough retooling of factories in place to create a new vehicle and put it on the market itself.

    So, industry does have the ability to plan. I mean, just look—I mean, if we look at SpaceX, bringing that rocket back and just being able to send a rocket up, you know, one of those cylinder rockets, right, that you used to imagine from the ‘50s goes up? And we used to just blow ‘em up and leave them in space. Now, we can actually bring them down and allow that piece of pipe with rocket fuel in it to land safely on land. That’s pretty amazing. You can’t plan that in three months. That takes years and years and years of planning.

    So, we have the ability to plan. The question is, in terms of our social imperatives, and that becomes a real question. So, why—what’s stopping people from saving? Why are people afraid? Why is fear so high now? And then also, going back to jobs as, we’ll call them no-skill jobs, start being eliminated from the landscape because grunt work is always the easiest to replace; thinking work is harder. Then, what do we do about that?

    And there are people out there offering solutions, but they are pretty dramatic, and there’s two, and they’re dramatic, and to even start contemplating that really requires a lot of courage.

    The first one is, is that there’s a good case to be made that we are at the end of the consumer based economy. Again, let’s go back to Ford. You know, an automobile for everybody changed everything. And when you look at it, you know, how many cars can Bill Gates drive? Well, if indeed, he had 365 cars in his garage, he could drive a different one every day. The fact is, he probably doesn’t, and he probably takes an Uber. So, really, in the future, you know, we’re all gonna be sharing cars.

    So, this notion of ________, and I didn’t do a good job explaining it. In other words, what I’m saying is that, for a lot of people, having devices and technology is what makes the economy run. Everybody needs a cell phone. Having mass distribution of cell phones makes the economy run. Having mass distribution of food makes the economy run. Mass distribution, mass distribution, mass distribution.

    Well, at some point now, what’s happening is, we can produce as much as we like. Production is no longer a problem. Two hundred years ago, production was a problem. The factories couldn’t make the stuff fast enough. Now, the factories can. So, now we have infinite production, which means we have infinite consumption, which means we have a problem with too much plastic in the water, and too much carbon monoxide in the air.

    Shimel: Bob, I’m gonna butt in here, if you don’t mind.

    Reselman: Okay.

    Shimel: So, I just got back from China last month.

    Reselman: Okay.

    Shimel: There’s a real problem there, right? Because this is—they’re living it, right? And, you know, we look at the world’s steel market and tariffs and all that stuff, a lot of it is being driven by—China has built over capacity in terms of what they can actually use and even sell at a decent margin in terms of steel.

    Reselman: Mm-hmm.

    Shimel: But not just steel, they are producing solar panels, cellular phones. They just—in other words, they are the kings of this, “Hey, we’ll produce as much as we possibly can produce because we’re gonna, if we’re not gonna consume it, we’re gonna sell it in the world market, and if we can’t make a profit on it, well, we’re not capitalists, anyway, right?”

    But an interesting dichotomy that I saw there was that they still are manually labor intensive in certain things. So, their streets are pretty clean in the cities, and the streets are clean because, on every street, there’s a cadre of people walking around with bamboo poles and palm fronds, kinda thing—literally sweeping the streets. And they sweep it into a pile and then some other person comes by and they have all these uniforms. And it comes by on a machine, like a Zamboni machine excepts it a vacuum, and sucks up what that people sweep.

    Reselman: Mm-hmm.

    Shimel: It’s almost like busy work to me, but what was fascinating to me is that, on one end, I took the bullet train from Shanghai to Beijing, right, and 300 and something kilometers an hour. And all I could see out the window, Bob, were endless cranes and towers going up, right? Not just a building, but cities and towns being built one after the next, and all built around factories. They’re like old factory towns, they kinda looked like, right?

    Reselman: Mm-hmm, mm-hmm.

    Shimel: So, they got the infinite capacity to build things, but I really question the infinite capacity to pay for things, to consume these things.

    Reselman: Right. Well, you hit it on the head. It’s the notion of payment. That’s sort of like, it’s like an assumption that we might have to start questioning, which leads into the second point that I was gonna bring up. You read my mind, Alan—and do my a favor, when you’re reading my mind, please clean up after yourself.

    Shimel: [Laughter] Okay.

    Reselman: Right, so the first point is, we have to start examining the role of consumption as a driver of an economy. We just gotta start looking at that. That’s a big question with incredible ramifications.

    The second one becomes this notion of paying for stuff in order to get what you want. And to—let me share a real life funny. My wife has decided that she needs—she wants to get rid of a chair we never use. It’s a nice leather chair that we never, ever use, and we paid, I think, $600—whatever it was, it was too much. I’m not a decorator, but she paid it, and now she’s saying, “I wanna sell it for $200.”

    And so, she puts the ad out on Craigslist and nobody’s biting, nobody’s biting. Why isn’t anybody biting? Because my suspicion is, it’s a good price for a $600 chair, but they can get ‘em for free. They can get probably an equal chair for free. And, if you look at the cell phone, I mean, we’re giving away cell phones. We’re giving it all away, we really are.

    And so, this notion of, what you’re saying is, how are people gonna pay for it? Probably they’re not. Either one of two things are gonna happen. Either the buildings are gonna be left unoccupied and it’s gonna be, there’s a downward recession—or the alternative is to blast credit into the economy to create money and to have that money become a purchasing agent. Is there wealth created? Is there value created? I don’t know about that. I don’t know about that. But are there transactions created? Yes.

    So, I’m being long-winded by saying that it might be coming time to start looking at a serious examination of universal basic income. And let’s just sprinkle the fairy dust for a moment, and let’s sprinkle the fairy dust and say that we’ve just—everything is great, everybody’s just calmed down. They understand that automation is great and if we let machines have their way, the machines can do just about everything now. And every week, you know, you get a check in the mail that allows you to go down to the grocery store or, better yet, interact with Amazon Prime, and the drone shows up with your food. And you go to your TV set and there’s your streaming TV. And some people decide they wanna be philosophers ________, so there are brain surgeons, and other people just decide they wanna sit around and play video games all day.

    There’s our future, right? Is that so bad? Is that so bad? And people say, “Well, how will we innovate? How will we go forward?” And my question—and I don’t have an answer for this—is, I wonder if somebody who gets into something like brain surgery for the money or curing disease for the money? Maybe the recognition, we don’t know. But the notion of universal basic income, if you take away the moral reservations about—what would they call it? The moral risk, right, becomes buyable.

    The sad thing is, is that any—the experiments that are being ________ aren’t real world. And what do I mean by that? They tried in Canada to ________. And I forget the details; I’ll mail it to your listeners if they want it. They’re running UBI on $1,000 a month. The test group got $1,000 a month. Well, gee, I mean, can you really live on $1,000 a month? That’s one thing. Whereas, if you go to another country that has universal basic income, and the poster child is Cyprus. Cyprus gives every citizen 500 Euros a month. The reason it’s relevant here is that a rent of an apartment in Cyprus is only 520 Euros a month. So, 500 Euros a month becomes, between—with two people, 1,000 Euros a month becomes a viable amount and a reasonable standard of living.

    That’s where UBI needs to be. We need to be starting to talk about UBI numbers in the area of $40,000, $50,000, $60,000 a year per family, and then we have to deal with the ramifications. And the ramifications really aren’t so much economic as they are social. What happens when you move the social structures that work bonds? In other words, what happens when a whole society no longer has to get up in the morning and go to work? What happens then?

    And that becomes the danger point, because most people have no idea.

    Shimel: Huh. Excellent. I think—yeah. I don’t disagree with you, there.

    Reselman: Well, again, I’m not looking for conflict or disagreement. This is a great discussion, but for our listeners out there, the point is—we are in technology. We are the people that write the scripts. There are other people that do the automation. We are the people that are making the robots. We’re doing all this. And we’re in a good position now, because unlike Henry Ford, who really didn’t think it through with regard to what an automobile would do over a period of 100 years, whereas one of the engineers at Sony did in terms of television. A friend of mine’s wife’s father worked at Sony, and he raised a question to one of his engineers back in—I think it was in the ‘80s. And he said, “You know, we’re selling a lot of Trinitrons. What are we gonna do when these all come back?” At least he posed the question.

    So, if anything, for the listeners out there that I hope they consider is, what do we do when we’ve become very good at all this? What do we do when we’ve created a framework and a fabric of automation where—and labor almost becomes unnecessary? What do we do, then? And what are the ideas behind that? And that’s where I wish there was more conversation, at the least. And not be on, “There will always be more jobs” or the fantastic stuff, but real, concrete, well researched conversation.

    Shimel: Excellent. Bob, I’d love to continue this conversation, but we are so way over our time. [Laughter]

    Reselman: Oh, I’m sorry, I’m sorry.

    Shimel: That’s okay! We’re gonna need to pick it up on another DevOps Chat.

    Reselman: Okay.

    Shimel: Which is great. I bet next month, we’ll do it again.

    Reselman: Sure, sure. Yeah. I’ll do that. I’ll make the coffee. The dog’s been very good here, he’s been very quiet. He understands that he’s being recorded, so.

    Shimel: Otherwise we’ll automate him out of a job. [Laughter]

    Reselman: Yeah. [Laughter]

    Shimel: Anyway, Bob Reselman—RoelBob, author, futurist, commenting on the state of the world today—thanks for being our guest on this DevOps Chat. We’ll continue this conversation on another DevOps Chat soon, but for now, this is Alan Shimel, and you’ve just listened to a DevOps Chat. Have a great day, everyone.

    — Alan Shimel