Category: Doin’ DevOps

  • Automation Challenges Holding DevOps Back

    Automation Challenges Holding DevOps Back

    A survey of 500 IT and engineering leaders in the U.S. published today finds organizations build an average of 6.7 internal applications per year themselves in addition to investing in 7.7 separate platforms to build applications.

    Commissioned by Internal, a provider of platforms for building application development environments, the survey also found organizations are spending 40% of their time building and maintaining these internal tools and workflows. While more than three-quarters (76%) of respondents said that this work is necessary, it distracts from building applications that drive business revenue. A total of 82% said a lack of true flexibility and customization is the top reason so much time is spent on building and managing internal tools and workflows.

    A full 94% of respondents said they want a more collaborative platform that enables technical and non-technical users to build internal tools/workflows faster together. The survey also found 91% of respondents believe a platform that encompasses application development and workflow automation would save development time.

    Internal CEO Arisa Amano said one thing that holds IT teams back is that managing the platforms used to build applications requires too much programming expertise. Internal is making a case for a graphical approach to building application development environments so IT administrators can easily construct them using a drag-and-drop interface on behalf of an application development team. That approach makes it possible to allocate more programming resources to building applications, she said.

    More organizations than ever are revisiting how applications are built as the number of projects increases despite an uncertain global economy, noted Amano. Organizations of all sizes are reluctant to hire additional full-time engineers even as digital transformation initiatives demand a growing number of custom applications, she added. The only way to effectively address those conflicting goals is to adopt a platform that automates much of the workflow associated with building an application development environment, said Amano.

    It’s not clear how willing DevOps teams are to replace the platforms they use today to build those environments, but many organizations are still relying on bespoke platforms they built and continue to maintain. Many of those platforms are made up of a collection of tools that DevOps teams cobbled together over the years. However, many of the software engineers that initially built those integrations may have since moved on and the documentation left behind is likely to be scant, noted Amano.

    Most DevOps teams in 2023 will continue investing in higher automation levels to accelerate application development. The quandary they all face is whether to continue to invest in the platforms they have already or migrate to a platform that makes it simpler to build and maintain an application environment using automated workflows built and maintained by a vendor. Regardless of what they choose, it’s certain the days when organizations could afford to throw engineers at every integration challenge have come to an end.

  • 5 Unique Challenges of Mobile App Testing

    5 Unique Challenges of Mobile App Testing

    At first glance, testing a mobile app may not seem to be very different from testing a conventional desktop app. Mobile and desktop apps are often written in the same languages and hosted on the same servers. They must also meet the same basic user expectations in areas like loading speed and accessibility.

    But when you dive into the details, you realize that mobile apps are fundamentally different beasts from desktop apps–and that, by extension, mobile testing requires a unique approach. You can’t simply take a software testing strategy that works for desktop apps and graft it onto your mobile apps.

    This article breaks down five of the main reasons why mobile testing necessitates a different strategy from desktop application testing and which unique needs QA engineers should consider when testing apps.

    1. Mobile Configuration Variability

    Perhaps the biggest difference between mobile and desktop testing is that with mobile apps, engineers have a much wider set of possible configurations to contend with.

    In the desktop world, there are just two main operating systems – Windows and macOS – and a relatively small number of OS versions for each family. And although there are many types of PCs and laptops, they all conform to the same basic hardware standards.

    In contrast, there are over 24,000 distinct types of Android mobile devices out there – to say nothing of iOS devices, which add to the diversity of hardware. There is also a wider selection of mobile operating systems and versions.

    What this means for QA teams is that there are many more variables to test for with mobile devices. It also means testing must be more efficient so that engineers can test for as many potential configurations as possible without delaying software release cycles.

    2. Lack of Mobile Testing Standards

    With a traditional, web-based desktop app, there is a consistent set of standards that the app is supposed to comply with when rendering content – specifically, the standards set by the W3C, a consortium that advocates for a standards-based, interoperable World Wide Web.

    In the mobile realm, however, there is nothing equivalent to the W3C standards. Apps can render content in widely varying ways, many of which are device-specific.

    Here again, this increases the need for specific testing teams to account for more variations and edge cases. With desktop apps, ensuring that the app complies with the W3C standards is often sufficient, but mobile testing is not so simple.

    3. Unique Mobile Accessibility Requirements

    Accessibility testing, which ensures that accessibility features like the ability to increase text size function properly, is important for delivering a great experience to all users, whether they access apps using desktops or mobile devices.

    But with mobile devices, accessibility testing is harder, because there is more room for error when implementing accessibility features. For instance, the smaller screen sizes of devices – and the greater variation in average screen size – could mean that an increase in text size will cause the app to render some text off the screen. Or, a “nighttime mode” feature on a screen could result in lower-than-expected contrast between text and backgrounds, causing accessibility challenges for some users.

    A mobile testing strategy needs to be able to accommodate risks like these, which aren’t as pronounced for desktop apps.

    4. Mobile Environment Differences

    By definition, mobile devices may be used in a wide range of physical settings. Depending on the location from which a user accesses a mobile app, application performance could be impacted by a variety of environmental factors that don’t typically apply for desktop apps.

    For instance, limited network connectivity might undercut application performance when users who travel too far from cell towers. Or, energy-saving features on mobile devices that are running on low battery could decrease the speed at which apps render content.

    Once again, these factors create additional risks that QA teams need to address when planning testing routines.

    5. Higher Stakes for Mobile Testing

    It’s a best practice to strive to deliver the best possible experience to all users, whether they are on desktop or not. But the reality is that poor user experience in mobile apps tends to have a more negative impact on a company’s brand.

    The reason why is that it’s easy for users to highlight poor app performance by giving apps low ratings or leaving negative comments in marketplaces. They can’t do these things for most desktop apps, because, unlike mobile apps, most desktop apps are not downloaded through centralized marketplaces with user-rating features.

    This difference doesn’t make mobile testing more technically challenging, and to be clear, I’m not saying you can skimp on desktop testing because users will abandon your desktop apps if they don’t work as they should, but it does increase the stakes of perfecting a testing strategy. Businesses simply have more to lose, reputationally speaking, from delivering buggy apps than they do from low-quality desktop apps.

    Conclusion: The Need for Purpose-Built Testing Solutions

    All of the above is why we need more testing strategies and solutions that are designed specifically for mobile.

    Historically, QA teams have frequently tried to extend desktop testing strategies to address mobile as they’ve added apps to their catalogs, but that approach simply doesn’t work. Mobile apps and devices are too different in fundamental respects to be shoehorned into a desktop-centric testing routine. The sooner QA engineers realize this, the sooner they’ll optimize their user experiences.

  • Stream Big, Think Bigger: Analyze Streaming Data at Scale

    Stream Big, Think Bigger: Analyze Streaming Data at Scale

    Data streams are all the rage. Once a niche element of data engineering, streaming data is the new normal—more than 80% of Fortune 100 companies have adopted Apache Kafka, the most common streaming platform, and every major cloud provider (AWS, Google Cloud Platform and Microsoft Azure) has launched its own streaming service.

    This shift is fueled by the growing demand to deliver events quickly, reliably and at scale to support a wide range of internal and external applications. From always-on, customer-facing applications to mission-critical operations, a growing number of use cases depend on subsecond updates—further upping the ante for real-time data processing and dissemination.

    There’s no doubt 2023 will be a big year for streaming technology.

    Meanwhile, as streaming moves toward ubiquity, we’re seeing another shift in the way businesses use the data: Analyzing events as they’re created for real-time insights. With the right tools in place, people can instantly compare what’s happening now to what happened in the past, triage problems as they occur and make time-sensitive decisions in the moment.

    With the proliferation of data streams, a new set of use cases and requirements for real-time analytics has emerged. To unlock the power of streaming in 2023, data teams will need to look beyond the traditional batch-oriented stack and adopt a streaming-native approach to the analytics architecture.

    The Streaming Paradigm Shift

    Data has always been at the center of how businesses operate. Until recently, we lived in a very batch-dominant world of business and data. The goal of data infrastructure was to identify data at a fixed point in time and store it for eventual use. The evolution from daily batch operations on mainframes to the internet-driven always-on world replaces fixed, static “data at rest” with fast-moving data in motion, as information flows freely between applications and data systems within and between organizations.

    Data at rest still exists, and batch systems continue to serve a variety of reporting purposes. But reality isn’t fixed or static, and to meet the demands for seamless, authentic data experiences, the systems we build must be designed for data in motion.

    Hence, the rise of streaming technology—and with it, a new mindset for how we think about data. As streaming increases, streaming data platforms increasingly act as an organization’s central nervous system, connecting the different functions and driving mission-critical operations. Evolving technologies are purpose-built to support data in motion systems: Stream processors and event databases.

    Apache Druid fits into the purpose-built category; as a real-time analytics database, it is designed to enable users to query every event as it joins the data stream and do it at a tremendous scale while enabling subsecond queries on a mix of stream and batch data.

    Thousands of businesses are already using streaming processors like Kafka and Amazon Kinesis with Druid to build cutting-edge systems that make terabytes to petabytes of streaming data accessible to applications and humans in milliseconds. Some of those businesses—including Reddit, Citrix and Expedia—were highlighted at Current 2022, the annual streaming event organized by Confluent.

    The next evolution of data intelligence is here, and it’s based on the ability to react to events as they are happening. But on the growth chart of streaming adoption, we are only at the beginning of an upward curve—a critical inflection point where streaming (and the technology that is built for it) starts to become the bedrock of everyone’s data architecture.

    So, when it comes to enabling scalable, subsecond analytics on streaming data, many developers and data innovators are wondering, ‘How?’

    We’re Streaming! Now What?

    At Current, we spoke with hundreds of Kafka users who were turning their attention to building out the next phase of their data streaming pipelines and embedding them more deeply into their organizations.

    While streaming adoption is becoming more widespread, most companies still have just one or two use cases they’re solving with a streaming platform. At Current, many people spoke about how Kafka effectively set their data in motion. But when it came time to analyze or put those streams to work in a user-facing application, their “data in motion” turned into “data in waiting” because their analytics system was designed for batch data, not streaming.

    To solve this problem, a new type of database is needed—and that’s why Druid was created. Turning billions or trillions of events into streams that can then be immediately queried by thousands of users simultaneously is where stream processors like Kafka, in combination with Druid, have unlocked a new set of capabilities that are enabling new developer-built analytics applications.

    For example, Reddit generates tens of gigabytes of event data per hour from advertisements on its platform. To let advertisers understand their impact and decide how to target their spending, Reddit needs to enable interactive queries across the last six months of data—hundreds of billions of raw events to slice and dice. But they also needed to empower advertisers to see user groups and sizes in real-time, adjusting based on interests (sports, art, movies, technology…) and locations to find how many Reddit users fit their target. To achieve this, they built a Druid-powered application that ingests data from Kafka and enables Reddit’s advertising partners to make real-time decisions and get the best possible ROI on their campaigns.

    Stream-to-Batch Vs. Stream-to-Stream

    Reddit chose Druid as the database layer of their application in large part because of its close integration with Kafka, as Druid was designed to ingest and analyze streaming data. This sets Druid apart from virtually every other analytics database, the rest of which were built for batch ingestion.

    Batch ingestion works exactly the way it sounds—it takes chunks of stream data, dumps them into a file, processes the file, then loads it into the database. Using a batch-based system to analyze streams introduces a bottleneck to your streaming pipeline. By contrast, Druid provides a connector-free integration with the top streaming platforms and handles the latency, consistency and scale requirements for high-performance stream analytics cost-effectively.

    In addition to out-of-the-box integrations, Druid has built-in indexing services that provide event-by-event ingestion. This means streaming data is ingested into memory and made immediately available for use. No waiting for events to be processed through batch processes before they can be queried. This capability, coupled with exactly-once semantics, guarantees data is always fresh and consistent. If there’s a failure during stream ingestion, Druid will automatically continue to ingest every event exactly once (including events that enter the stream during the outage) to prevent any duplicates or data loss.

    However, perhaps the most powerful reason to use Druid for streaming data analytics is its near-infinite scalability. For even the largest, most complex ingestion jobs, Druid can easily scale into the tens of millions of events per second. With variable ingestion patterns, Druid avoids resource lag (as well as overprovisioning) by enabling dynamic scaling. It combines the query and ingestion performance of shared-nothing architecture with a cloud data warehouse’s flexibility and non-stop reliability. This means you can add computing power and scale out without downtime or rebalancing, which is handled automatically.

    In essence, while using a cloud data warehouse to serve both batch-oriented and real-time use cases might sound efficient, doing so defeats the purpose of a streaming pipeline.

    “The weakest link in the chain sort of dominates everything,” Databricks CEO Ali Ghodsi told the audience at Current. “If you have one step of your pipeline that is batch-processed and really slow, then it doesn’t matter how fast you are in the rest of the pipeline.”

    That’s why when Confluent’s data engineering team needed to build a real-time observability platform, they chose to use Kafka and Druid together. Today, the platform ingests over five million events per second from Kafka and handles hundreds of concurrent queries from a large team of analysts.

    “We do a lot of things today that we didn’t imagine doing three or four years ago,” Matt Armstrong, who leads the observability and data platform team at Confluent, said in a Druid Summit 2022 interview. “From a [product] perspective, you could think of Druid as being able to power a great product [Confluent Cloud] with a great support experience—but perhaps more importantly—an unconstrained future.”

    It’s Time to Think Big

    We’re already moving to this entirely new way of thinking about moving, analyzing, and sharing data. Streaming technology has opened the door for a plethora of new use cases and products to come to fruition. We believe organizations that view streaming data as a force multiplier and implement a streaming-native approach to analytics will gain a competitive advantage in 2023 and beyond.

    Druid is purpose-built for these new streaming use cases, but it’s also built for a new type of application—one that draws characteristics from both the analytics and transactional database worlds. Industry-leading teams have built mission-critical applications that enable operational visibility, customer-facing analytics, drill-down exploration and real-time decision-making using streaming data and Druid. This trend is now starting to take hold and the next wave of analytics applications is already being built.

  • What’s Ahead for the Future of Data Streaming?

    What’s Ahead for the Future of Data Streaming?

    Data is everywhere. It’s being produced by almost everyone and everything around us. For businesses to be competitive, they need to build resilient, scalable systems that can efficiently tap into and react to this ever-increasing volume of data. Companies are meeting this need by moving to real-time data streaming to develop new solutions and improve their businesses and customer experience.

    This category of data streaming has been growing. And, driven by the rise of real-time digital experiences like ride-sharing, fraud detection, inventory management and more, the growth has accelerated.

    So what’s next for data streaming?

    Data as a Product Grows in Popularity

    The concept of data as a product will become more mainstream. Across many industries, data streaming is becoming central to how businesses operate and disseminate information within their companies. However, there is still a need for broader education about key data principles and best practices, like those outlined through data mesh.

    Data as a product is foundational to rethinking how data produced in one part of a business can be reliably used in another. Data products with formalized ownership and responsibilities, combined with a platform for discoverability and accessibility, result in significantly fewer barriers and a much easier data access experience for all. Schemas, the Kafka API and maturing specification standards like ASyncAPI can be a part of this evolution.

    As more folks embrace this mindset, I expect to see companies shift from using ad-hoc data pipelines to ones based on data products, driving a centralized system that can power both better analytical insights and operational execution.

    Growth of Self-Service Solutions

    With the rise of cloud-based offerings, I expect to see more companies offering more accessible, pay-as-you-go, self-service solutions. We’ve already seen this shift over the past few years; cloud-based offerings are making it easier for companies to try out a data product based on their usage (or lack thereof). Given the current market conditions, these offerings will be more appealing to organizations that aren’t ready to sign a multi-year contract for a product offering or focus solely on a single technology.

    Increase in Cloud Migrations and the Continued Rise of SaaS

    Cloud is here to stay. We’ve proven that it works, that it’s safe and secure, and for many folks, it just makes sense. This should come as no surprise to anyone, but expect the trend of cloud migrations to continue.

    In the context of Apache Kafka, building out a Kafka-based data streaming solution used to mean hosting and managing your own Kafka cluster. If you’ve ever been in that position, you know that usually means more DevOps work and less focus on building applications to get the most out of your data. Not only do cloud-based Kafka offerings eliminate much of the DevOps headaches that come with a Kafka cluster, but they also make it much easier and faster to hit the ground running and begin streaming your data.

    I’m personally excited by what the cloud and SaaS can do to make Kafka and data streaming more accessible. In my visits to developers and companies around the globe, I see this enthusiasm shared by so many. Entire geographic regions and industries are taking the opportunity to move to the cloud and dive headfirst into data streaming.

    KRaft Leads to Rise in Kafka Adoption

    As of Apache Kafka 3.3, the KRaft consensus protocol has replaced Zookeeper and is production-ready. Cluster metadata can now be maintained and managed from within the cluster, meaning there’s one less thing to worry about when deploying Kafka instances.

    While there are many options for cloud-based Kafka-as-a-Service, improvements such as KRaft in open source Kafka make self-hosting even easier. This, along with the work done to make it simpler to run managed Kafka services on local machines and test environments, means that Kafka no longer has to be synonymous with complexity. With the difficulty of managing and maintaining a Kafka instance no longer preventing folks from making use of data streaming, I predict that the adoption of Kafka will increase even more.

    Data streaming will continue to mature as a transformational technology for companies of all sizes, serving as a critical infrastructure that most organizations will need to run their business.

    If you haven’t yet explored what data streaming has to offer you, maybe this will be your year to check it out!

  • The Strategic Product Backlog: Lead, Follow, Watch and Explore

    The Strategic Product Backlog: Lead, Follow, Watch and Explore

    The economic outlook for 2023 suggests many organizations will be leading through a period of resource scarcity as IT budgets are scrutinized and organizational priorities are re-evaluated. For the product manager, smaller budgets and fewer resources place even greater emphasis on ensuring alignment between enterprise priorities and the product backlog.

    Many tools are available to help product managers prioritize individual work items at a tactical level for DevOps teams. These models generally seek to quantify some combination of internal stakeholder value and level-of-effort required for developers and DevOps teams to complete. Higher-value lower-effort items rise to the top.

    Other strategic factors are just as important in the prioritization process, particularly for products living within a larger enterprise product portfolio and competing for scarce resources. For these, a product manager must understand why a given work item or capability should be given priority and how it should be pursued. This involves asking questions such as: On what basis should an item come into the product consideration set? How much should DevOps and developers seek to innovate in delivering a specific capability or feature? What is the product and the portfolio-level opportunity cost of pursuing a given piece of work?

    A strategic model for backlog evaluation helps to set expectations with DevOps, developers and other internal stakeholders and ensure customer needs are front and center in prioritization decisions. It establishes a common language for collaboration. Two dimensions should emerge in evaluating capabilities at higher product and portfolio levels: Capability alignment to business-level strategy and the potential for a capability or feature to not just satisfy but captivate customers with a novel or compelling experience.

    The intersection of business strategy and customer experience factors can serve as a useful model for a product manager to think strategically about their backlog. The model helps to inform not only the question ‘Should we do this?’ but also ‘How should we proceed?’ and make things clearer for DevOps teams.

    Lead

    Items in this quadrant are the unicorns of the backlog and have the greatest potential to both strategically differentiate a product or enterprise and captivate customers. Product focus in this quadrant should be to invest in innovative, industry-leading approaches to satisfying customer needs in a manner that is consistent with business strategy and unique selling proposition. These items should receive the highest strategic priority on the product backlog.

    Follow

    Potential work items in this quadrant have a high potential to delight customers if handled well and irritate them if not. However, these elements are unlikely to be competitively differentiating given the current business strategy. Product focus in this quadrant should be to continually assess competitor treatment of these elements and adopt proven best-in-class experiences within the industry and adjacent industries. The product should focus moderate priority on competitive intelligence for elements in this quadrant and follow existing competitor approaches that enhance the customer experience.

    Watch

    Items in this quadrant are generally not problematic for customers. They are unlikely to differentiate the product or enterprise from competitors given the current business strategy and should be given low priority. The product should monitor proposed solutions in this quadrant to ensure no unnecessary customer effort is being introduced by other backlog items.

    Explore

    Product functionality in this quadrant is either not problematic for the customer experience or represents capabilities that are still emerging in the marketplace. These elements have a likelihood of developing into competitive levers, provided they can be developed in a manner that enhances the customer end-to-end journey. The product should place a high priority on product discovery for elements in this quadrant. It should explore capability innovation through design thinking or similar customer-centered ideation approaches.

    Mapping a product backlog to these four quadrants is as much art as science. It requires a deep understanding of business strategy, intended outcomes and customer needs. As with any strategic model, its value comes from the quality of discussions it produces and its role in surfacing implicit assumptions from the product’s stakeholder group, including DevOps teams and developers. Whatever model is used, having a mechanism to drive strategic product discussions is a critical tool in the product management toolbox and an important step to product management maturity.      

  • Microsoft Outage Outrage: Was it BGP or DNS?

    Microsoft Outage Outrage: Was it BGP or DNS?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

  • Digital Experience and the Future of Observability

    Digital Experience and the Future of Observability

    Over the past two years, there’s been significant hype around observability in the IT operations and DevOps world. As shorthand for providing better insights, observability has seen a rise in lockstep with distributed architectures, cloud-native applications and the increasingly complex IT environments associated with them.

    As we round out 2022 and move into the new year, there’s evidence observability is gaining mainstream adoption by IT operations and has begun to take off, with the market reaching a better understanding of what observability is and why it matters. This broader adoption offers a moment to reflect on the impact of observability so far and how it will continue to evolve in the year ahead.

    What is Observability?

    Though there’s ongoing debate in the industry about what observability actually means and what an observability platform should include, most people in the industry will argue observability is the evolution of monitoring and promises to offer more complete answers than standalone monitoring. Gartner, for example, first asserted in 2020 observability is “the evolution of monitoring.” But the two aren’t mutually exclusive, and observability and monitoring will continue to coexist and fill distinct needs for different teams based on what information they need about their environments and how they need to act on it.

    So far, observability has had the most considerable impact on application performance and digital experience monitoring.

    The days of monolithic applications are over. Instead, modern applications are highly distributed, are built natively in the cloud using container technology, are organized around microservices and leverage databases in multiple cloud environments. These increasingly distributed software stacks have introduced enormous flexibility for developers but huge complexity for operations teams, making it harder to deliver an optimal experience to the end user. The DevOps teams tasked with building and managing custom web applications are under pressure, and the result is, as one recent article so concisely put it, “Devs don’t want to do ops.”

    Observability has provided a welcome respite for DevOps teams who need intelligent visibility into their environments to determine how applications are performing. This has made application performance a key focus for many observability providers.

    An Intolerance of Bad Digital Experience

    Ensuring external customer-facing applications are performing optimally is the key driver behind this. Digital businesses with external applications core to the company’s success need to ensure those applications perform optimally—customers are fickle. They’re intolerant of bad digital experiences, and alternatives are plentiful. Any e-commerce vendor knows no website equals no sales.

    Traditional application performance monitoring (APM) tools look at telemetry to flag application issues or outages needing to be addressed. But understanding the health of your applications from this narrow standpoint isn’t the same as understanding how the applications perform from a user perspective. In other words, if you aren’t considering how applications are performing (or not!) for customers, employees and other users, you’re not seeing the forest for the trees. Observability helps solve this by elevating APM into a more holistic digital experience approach by adding visibility into how the end user engages with your application.

    By providing a view into how an application is performing with the context of what’s happening throughout the entire stack—including networks, databases, systems, and more—and how issues are impacting the user experience, DevOps teams can shed light on previous blind spots.

    Elevating the importance of digital experience through observability enables teams to understand and respond to issues more efficiently and provides critical data to help DevOps teams further improve their apps beyond just debugging and issue remediation. By understanding how users engage with and experience the application, you can gather critical data to improve or simplify the digital user experience. In our e-commerce example above, this could mean fewer clicks or an easier checkout experience (better digital experience = more sales).

    Cloud migration efforts, coupled with ongoing hybrid and remote work and understaffed tech teams, make prioritizing what matters most even more important. Focusing on the experience of the end user—but with end-to-end visibility across the environment—allows stretched DevOps teams “do more with less.”

    2023 Will be the Year of Digital Experience Observability

    An observability approach prioritizing digital experience is the first step toward building a complete customer-centric environment. This eliminates the potential risks of missing issues directly impacting application performance and creates an enhanced, complete experience for every user. This will make 2023 the year of digital experience observability.

  • 8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: New ideas bring low-power ML inference, and more big-tech jobs are going. (more…)

  • Optimizing the Developer Experience in 2023

    Optimizing the Developer Experience in 2023

    2022 was a banner year for innovation, but not only in the traditional “churning out new features” way. Many organizations started thinking about their processes and how to amplify them to maximize efficiency and employee retention. And when they started digging, companies realized that the developer experience was a major pain point that could be rectified–and a ripple effect of positive gains would result.

    Companies started looking more closely at how the tools and processes developers use support and enhance their work. Great tools and thoughtful processes boost developer happiness and satisfaction. And when those levels rise, guess what else increased? Productivity, efficiency and employee retention rates.

    We saw this trend of developer support take hold last year, but with more work to be done across many companies, we’ll see it continue in 2023 and beyond, impacting just about every facet of tech in new ways. Many companies have realized what does work by trying what doesn’t work and are making big changes from there.

    Shifting Results

    A major player in the changing developer experience has been the shift left approach that’s taken hold in recent years. About 80% of organizations have said they are adopting this idea of moving more of the responsibility for security and compliance to the front of the pipeline to avoid a compliance scramble at the point of delivery. The result, however, is a compliance process that ends up being more complex and less efficient, putting additional burdens on developers.

    Involving more people creates more opportunities for security breaches and slows down the entire software delivery life cycle. It also shifts security responsibilities to developers and requires them to do significantly more than is listed in their job description. In fact, 60% of those shifting left said their development team is bearing the burden of the change. Rather than focusing on writing code, developers have been called on to understand regulatory policies, build regulatory controls into their applications or pipelines, inspect massive log files generated by more and more diagnostic tools for security info and spend more time in meetings to discuss audits. That’s not a recipe for fulfilled developers; it’s the path to a loss of innovation.

    Stop Paying the Compliance Tax

    When developers–or anyone on your team–are tied up in compliance tasks, they aren’t spending that time in profit-earning efforts. This “compliance tax” costs companies an estimated 15% each year–that’s 15% of their time spent managing compliance instead of innovating or providing services that add value. That’s not to say that compliance isn’t important–it’s essential, in fact–but limiting the burden of compliance improves the overall experience of developers.

    When developers aren’t innovating, they’re not happy. They want to be writing great code, not translating regulatory governance policies. In today’s culture of quiet quitting, companies simply can’t afford to turn over compliance tasks to developers. It’s a waste of their talent and a surefire way to lose great developers and the chance to attract new ones.

    Shift Left, but Do it Right

    The good news is the compliance tax is largely avoidable. Instead of shifting responsibilities left, shift compliance everywhere. No one person or group, including developers, should be in charge of these tasks–that approach just isn’t comprehensive enough to ensure security and compliance throughout the software delivery life cycle.

    Instead, security and compliance should be moved away from a point-in-time part of the cycle to a continuous process built into every step of the life cycle. CI/CD reduces the burden on any one person or group and is proven to be more efficient at catching anything that is non-compliant. When the tools are doing the heavy lifting, the people aren’t making as many mistakes and non-compliant code isn’t slipping through.

    Baking in compliance allows developers to spend more time doing what they do best: Creating amazing features. This, more than anything, will boost the developer experience. Developers want to create and, when they experience the right environment and the right resources, innovation tends to happen.

    Beyond the Developer Experience

    Focusing on the developer experience pays off in more ways than just creating happy employees (though that alone is reason enough to make a change). Innovative developers are the backbone of leading tech companies. When they’re churning out new features that are getting public recognition and are touting a culture with a positive developer experience, companies attract more talented developers and the innovation loop continues.

    So, if you’re looking for more innovation in 2023, start where you’ve always started: Your developers. Set them up for success by automating what can be automated and baking in the mundane – yet essential – tasks to truly optimize the developer experience. Then sit back and watch what incredible capabilities your developers can generate.

  • FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

    FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)