Tag: automated processes

  • No-Code Automated Software Solves a Host of Problems

    No-Code Automated Software Solves a Host of Problems

    There’s a huge disconnect in corporate America, and it’s costing companies big time. The disconnect involves software testing, or, more precisely, the lack of it. More than nine out of 10 CEOs are confident that their company’s software is tested regularly, yet roughly eight out of 10 product testers reported that up to 40% of their software goes out the door with insufficient testing. This dichotomy came to light in the latest Leapwork survey of 500 CEOs and software testers.

    The consequences of untested software are potentially dire and far from hypothetical. Flawed software that delayed the launch of new car models contributed to the dismissal of Volkswagen CEO Herbert Diess, while Facebook saw its market cap value plummet by billions in 2021 when a software glitch came to light. 

    It’s not as if anyone is unaware of such risks: A whopping 95% of CEOs surveyed admitted they’re concerned about losing their jobs if a software failure occurs, while 76% of testers shared that concern. Those feelings are certainly valid, as more than three out of four CEOs reported that software failures damaged their companies’ reputations during the past five years.  

    Despite these realizations, CEOs seem willing to gamble. A full 85% said they considered it acceptable to release software that wasn’t adequately tested, as long as it can be patched later. That attitude has made patching standard operating procedure. More than half the testers said their teams spend five to 10 days a year patching software. 

    Why are organizations willing to take unnecessary risks by releasing software that’s potentially not ready for prime time? There are several common reasons—and a solution that many are overlooking. 

    The Problem with Manual Testing

    One of the major problems is the continued reliance on manual testing, which requires time and resources companies can’t afford. Only 43% of testers said they use automation to some extent in their testing, proving that the majority of testing is still a manual process.  

    That significantly slows product development, an issue for businesses anxious to get their products to market before the competition. Nearly 40% of CEOs said the time-consuming nature of manual testing is one of the primary reasons they release programs that haven’t been properly vetted. Testers clearly feel the crunch, with about one in three saying faster development cycles don’t allow enough time for testing. 

    Given the choice between rushing through testing or delaying a release, companies often roll the dice and opt for the former.  

    Two recent pandemic-related trends have made the situation even more difficult. More organizations are embracing digital platforms to cope with the effects of COVID-19 on their businesses, increasing the need for IT talent. At the same time, upheaval in the labor market has resulted in widespread resignations and job hopping, contributing to a serious shortage of skilled IT personnel. 

    The Coding Conundrum

    Even in this chaotic business climate, experienced software developers remain a hot commodity, with many career options at their fingertips. The competition for talent has left many IT teams scrambling and understaffed, making it difficult to produce high-quality software at a breakneck pace.  

    Eliminating the need for manual testing could relieve the pressure to a great extent. By automating testing, organizations can reduce the burden on staff and minimize the risk of errors caused by deadline pressures. That would allow more testing of more software in less time, which would help move product out the door and into the hands of customers. 

    But automated testing isn’t without its challenges, as many organizations have discovered. Many solutions that are billed as “low code” still demand coding skills beyond the capability of typical business users and testers. That need for coding is an obstacle that can drag down the pace of testing and make it difficult for business users to participate in the process.    

    That challenge grows as the need for ongoing maintenance expands. The test engineers who came on board to set up an automation solution can find themselves bogged down in maintaining code. As a result, speed to market continues to suffer. 

    Democratizing the Test Process

    There is a solution: true no-code test platforms. This type of solution allows both testers and business users to design, run and maintain tests without the need for coding. Business users who understand how the software deliverables are supposed to grow business can be intimately involved in testing, which enhances the quality and functionality of the product and the satisfaction of customers. 

    It also promotes speed. When testing is largely automated and more people are involved, it’s possible to test more software in less time. This eliminates bottlenecks and addresses the issue of scale. The use of automation on a no-code platform has been shown to speed time to market by a factor of 10—an improvement that largely eliminates the need to rush potentially flawed software to market without adequate testing.   

    Organizations can position themselves to meet the growing demand for digital solutions by revamping the way they test software. By eliminating manual testing and adopting an automated platform that doesn’t require coding skills, they can afford to test all their products thoroughly. The end result: They can minimize the risk of bugs that could undermine their success and threaten job security.  

  • DevOps is More Than Just Automation

    DevOps is More Than Just Automation

    DevOps is a lot of things. What DevOps is, what DevOps does and how an organization adopts and implements DevOps tools and practices are largely subjective, but there are some foundational elements that are fairly ubiquitous. One of which is automation. As pervasive as it is, though, DevOps is not automation and automation is not DevOps.

    The Preface of “The DevOps Handbook” lists a number of prevailing myths about DevOps, including the idea that DevOps is just “infrastructure as code” or automation. The book goes on to explain:

    While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.

    The book also shares an anecdotal quote from technology executive Christopher Little: “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”

    I prefer a golf analogy. If DevOps is the game of golf, then automation is like the putter. The game itself may be played for different reasons by different individuals—exercise, competition, just to get out and enjoy nature—but the fundamentals are the same no matter what the ultimate goal is. There is a wide variety of clubs available and strategies that can be employed to get the ball from tee to green, at which point the putter is somewhat indispensable. It is technically possible to tap the ball in using some other club, but everyone will agree that the putter is the best tool for the job. As necessary as a putter may be, though, the putter is not golf and golf is not the putter.

    The important thing to remember is that automation is simply a tool or method for achieving the goal. It, like any other facet of DevOps, has to be part of a broader cultural shift and mindset.

    It was about a year ago that I theorized that microservices could make the “Ops” in DevOps obsolete. If everything—infrastructure included—can be implemented in code and automated, will we still need people to be involved? The answer then—and now—is yes, because DevOps is about more than just automation. Its evolution is to one of enabler rather than job-killer. As more functions are automated, people can focus on bigger and deeper issues and create new innovations instead of focusing on mundane, repeatable tasks.

    You can’t do astronomy effectively without a telescope, and you can’t play golf effectively without a putter. Similarly, you can’t effectively do DevOps without automation—but it is theoretically possible, because it is just one element of DevOps.

    I can’t imagine why anyone would want to do DevOps without automation, though. It wouldn’t make any sense—like trying to look at the stars without a telescope, or sink a golf ball from 18 feet with an 8-iron. Although DevOps is more than just automation, the most effective and efficient way to succeed at DevOps is to automate everything that can be automated so you can stay focused on the big picture.

    — Tony Bradley

  • What Do We Do When Everything is Automated?

    What Do We Do When Everything is Automated?

    Recently, I came across a study the caused me to think beyond the day-to-day world of code-slinging in which I live. According to the study conducted by Center for Business and Economic Research at Ball State University in Indiana:

    “Almost 88 percent of job losses in manufacturing in recent years can be attributable to productivity growth, and the long-term changes to manufacturing employment are mostly linked to the productivity of American factories.”

    Just translate the term “productivity of American factories” into the word “automation” and you get the picture. Other workers are not taking jobs away from the gainfully employed, machines are.

    This is not a new trend. It’s been going on since before Eli Whitney invented the cotton gin. Industry creates machines that do the work of humans faster, cheaper, with more accuracy and with less failure. That’s the nature of industry; nothing new here. However, what is new is rate by which the displacement of human beings from the workforce in happening.

    The Bureau of Labor statistics projects that by 2024 the U.S. economy will need 50 percent less car mechanics, 42 percent less telephone operators, 26 percent less postal clerks and 20 percent less parking enforcement officers. Or, to put it another way, cars will be better at self-repair, call routing technology will get better at conducting verbal conversations with humans, self-service postal machines will get better at taking care of human transactions in the post office and parking meters will know how to write tickets.

    Here’s another another point to ponder. As the quality and reliability of self-driving vehicles improve, it’s not far-fetched to imagine self-driving trucks becoming the norm on the nation’s highways. How many truck drivers will be displaced once self-driving trucks are everywhere?

    Also, think about this: As Uber and Lyft mature in the business landscape and self-driving cars become commonplace, the ride-share companies will replace human driven vehicles with self-driving vehicles. Then, Uber or Lyft will start to offer a pricing model that is flat fee for 24/7 service with unlimited mileage. So, to keep it personal, imagine Uber/Lyft offering me a deal in which I pay $150 a month to have all my driving needs taken care of. Or, I can continue to pay the $400 it costs me for my car lease and insurance coverage (yes, I lease a modest vehicle). Which way do you think I will go? Spend $400 for the pain of driving in a car in LA traffic or spend $150 to get where I need to go while I read a book in the back seat? Me? I’d fork the car over in a New York minute.

    As if this isn’t startling enough, try this one out: Walk down your street. See all those cars parked on the side of the road. In the near future, using the Uber/Lyft automation scenario, they won’t be there any longer. Any car made will be used 24/7. All this translates into less cars doing more work. And less demand for cars means less cars being made. Less cars being made means less people working making cars. You get the picture.

    What about software? Let’s take a scenario that is part of my day-to-day coding world, logging. In the old days, you’d log to a file on disk. Over time, that log file got so large that a human would need to move the file manually onto an archive disk so as to not eat production space. Somebody comes along and says, “Hey, I can write a piece of code that watches the size of the log file and moves it automatically when the file gets too big.” So much for the person doing the manual file move. But, still, you had to keep adding capacity to the archive machine, which typically meant a human walking down to the server room and twiddling with some hardware. Then a someone has a great idea, “Let’s use this thing called cloud storage as a back-end for a log collection service. We’ll leverage the elastic capacity features of cloud storage and write out logs to that service. Hell, why make a service? We’ll subscribe to an existing one and save the development costs.” Thus, no more humans needed to monitor capacity, move files, write incidental scripts—any of it. In terms of logging, a bunch of automation is doing the work a lot of humans used to do. Is this progress? Might be. But the trend is unmistakable, so much so that I have no problem imagining a future in which 90 percent of work that used to be done by humans is done by low-cost, automated, robotic, labor.

    We’ve always been on our way to automating everything. The only difference between then and now is that now we are really, really close to full automation. Asking the question, “What will we do when everything is automated?” is no longer fantastic, it’s essential.

    So what will we do?

    “Simple,” you say. “We’ll retrain the displaced workers.” Really? Many of us in the software game know that notion of retraining is a joke. If you are not constantly learning the new stuff, you are out of work. For a knowledge worker, continuous learning is an ongoing requirement for commercial viability. And, the baseline from which you are learning is very high. In other words, you need to know a lot to get the basics of how to write a deployment script in Ansible that runs against AWS. And, even as you are learning that basic technique, somebody is already creating a technology that will make the technique you are learning obsolete.

    So back to the question, what do we do?

    First, let’s do the obvious. When near total automation has the result that there is no longer any work for most humans to do, we need to come up with other means of survival. Survival in the modern world means having money to live on. Charles Murray suggests in the Wall Street Journal that we plan to implement Universal Basic Income. Finland is starting a pilot project based on the idea. Other countries are experimenting too. Universal Basic Income is a program in which citizens of a state are provided with a base income on which to live. Some programs vary basic income according to income produced otherwise. The common thread is an understanding that jobs are not plentiful and that depending on one for survival is not realistic.

    The notion of Universal Basic Income is not that new. It’s been around since the 1960’s, proposed by folks such as Milton Friedman as the negative income tax.

    Second, we need to address the elephant in the living room: the birth rate. In the old days when agriculture and small, private farming was a major industry in the United States, having a large family made sense. You needed your family members to work the land. As the Industrial Revolution created demand for factory workers regardless of age, large families still made economic sense. But now the trend is that we need less people to do more. Thus, having large families becomes counterproductive to the economy overall. Yes, there are certain sensibilities out there that encourage large families and adherents to such thinking have large families as a matter of choice. Still, many families end up with large families for reasons other than intention. It just sorta happens.

    Thus, to ensure that humans have a chance at a viable existence in a fully automated world, implementing effective family planning policy and practice becomes as useful to the society of the near future as the anti-smoking efforts that started in the 1960s does today. I am not advocating draconian, government mandated family planning. We cannot legislate family size anymore than we could smoking behavior. Rather, we need to create a social condition in which the wisdom of the idea prevails.

    Finally, we need to address the need for human dignity in a fully automated world. For better or worse, we need to accept that in the near future the traditional relationships between demand, productivity and income no longer may be applicable. The old days of human workers making stuff and getting paid for their product or labor are coming to an end. Yet, one of the intangible benefits of the old days was the dignity and satisfaction that went with pulling your weight and earning your keep. Being able to provide for yourself and your family defined your worth in your own eyes as well as those around you. This need for dignity will remain no matter how the technical and economic landscapes evolve.

    When I started to doing the research for this piece, I asked others in the know to respond to the prospect of a world that is fully automated. One the people I talked to was Phillipe Kahn, founder of Borland, Starfish Software, LightSurf Technologies and most recently, Fullpower Technologies. Here is his response:

    “I remember being in India and watching a construction site: Lots of people, elephants, activity. I asked, ‘Why don’t you all use bulldozers and tractors and prefabricated concrete parts?’ The answer was enlightening: ‘How would this community make a living with dignity?’ That’s the whole paradox that we are dealing with: Productivity versus dignity for communities that could be unemployed for generations.”

    There is a difference between work and labor. Work is an activity a human does to give one’s life meaning. Labor is what a human does to survive. In the old days work was your avocation, labor was your vocation. Some humans were fortunate enough to have their activities be both avocation and vocation. Others went to work in factories, farms and offices to earn a buck. They pursued other interests at other times. But whether you sang in the New York City Opera full time or in the choir on Sunday morning, the dignity of your work, bringing music to the ears of other humans, was in full force.

    So, the final part of answering the question, “What do we do when we’ve automated everything?” is this: Preserve the dignity of the person and the community. A fully automated world will be a wealthy world unless we blow it up. Productivity produces wealth. That’s the way it is. Regardless of who is or what is the owner of the wealth—government, corporation or private citizen—sharing will become more important than ever. Concretely, this means allocating a significant amount of money to people and organizations that do work that has little or no commercial value, but extraordinary amounts of human value. When it comes to commercial value, the machines will have that end of the economy covered and then some. However, stuff that has little commercial value—curing low occurrence diseases, space exploration, academic research, expanding the arts—this is where human activity can excel.

    In the old days we had a notion called the commonwealth, that shared space where our individual assets grew. We shared some to get some. In the automated future it might have another name. But no matter the name, it will be a place where humans work with dignity in communities and most labor is the left to automated robotics. If not, the common thread of our individual survival might indeed be nothing more than alms for the poor while automation creates wealth for a few.

    — Bob Reselman