devopsy.kinsta.cloud

Category: Doin’ DevOps

  • 3 Technologies Driving Business Sustainability

    3 Technologies Driving Business Sustainability

    The pandemic highlighted many things, not least of which was the shift in consumer behavior toward further encouraging companies to change their operations and act with sustainability in mind. An overwhelming 96% of businesses said the pandemic shifted their focus to the social component of environmental, social and governance (ESG) strategies. Technology has been a key player in helping corporations quantify and tackle ESG issues in their sectors.

    A recent PwC and WEF report outlining the use of technology to drive large-scale sustainable change looked at 300 cases of emerging technology in relation to achieving global sustainable development goals. The study found 70% of their 169 targets could be enabled by technology applications.

    With the link between sustainability and technology clear to see, here’s where technology and innovative thinking are boosting sustainability in three key industry areas.

    Energy, Utilities & Resources Are on a Sustainable Transition Journey

    With 30% of overall greenhouse gas emissions stemming from power plants, it is not surprising that utility companies are under intense scrutiny and pressure to transition to green energy. Many are actively investing in renewable energies such as wind farms, hydro stations and solar power. “Green steel” is at the center of America’s 2030 greenhouse gas pollution reduction target, and the U.S. already generates around 11.4 million tons of hydrogen per year. All eyes are on these green steel initiatives that are showing that, with the right resources, there is plenty of potential to decarbonize the U.S. energy, utilities and resources sector.

    A Swedish partnership, which includes Europe’s largest iron ore producer and IFS customer LKAB, has delivered the first fossil-free steel in the world. The steel was made with 100% fossil-free hydrogen instead of coal and coke—paving the way for a completely fossil-free value chain for iron and steelmaking.

    As experienced by LKAB, enterprise software can strategically support the shift to a more sustainably focused energy, utilities and resources sector. To thrive, new business collaborations and joint ventures must be agile and able to develop at pace, unencumbered by restrictive enterprise solutions; to achieve both these goals, cloud deployment and full supply chain sustainability is key.

    Manufacturing–Closing the Loop Requires Supply Chain Visibility

    The manufacturing sector is another major industry facing complex challenges—and opportunities—on the path to sustainability. The time is now for manufacturers to drastically change their linear approach of material, manufacture, dispose and move toward a circular economy of reduce, reuse, recycle. This means adopting reverse logistics methods enabling manufacturers to integrate more environmentally friendly practices into their manufacturing processes.

    According to a recent Deloitte op-ed, “Through the use of digital technology, manufacturers may already have a head start in their sustainability journey. In recent years, the implementation of lean processes using digital capabilities has boosted productivity, created safer workplaces and reduced costs.” For example, enterprise resource planning (ERP) software is helping manufacturers to develop and maintain the overall life of a product by using data and tracking of which areas need more sustainable practices. For instance, manufacturers embracing a circular model can rely on ERP software to help them maintain, recondition, recycle and support a product over an extended life cycle.

    And again, the software can incorporate environmental footprint management tools to capture the footprint of their product over its life cycle and present information that can be used for better decision support. By analyzing the percentage of post-consumer waste used in a product, manufacturers can then see where they can maximize the reutilization of components and preempt sustainability challenges.

    Aerospace and Defense—AI Predicting a Cleaner Future

    Every industry has a part to play in reducing carbon emissions, and the aerospace sector is no different, so it’s necessary and right that the industry is taking significant steps toward improved sustainability. Some of the key enabling technologies that will support this are highlighted by Global Data in its Thematic Research on ESG in Aerospace and Defense. The report highlights: “Electric aircraft, hydrogen-powered aircraft, and sustainable aviation fuels (SAFs) are key innovations that will shape the future of air travel. Improving social sustainability is vital for companies seeking to earn government contracts, increasing visibility and improving management throughout the whole supply chain will be vital.”

    From the Silver Spirit to the Spirit of Innovation

    Leading original equipment manufacturers (OEMs) are highlighted in the report for applying innovative thinking to solve industry emissions challenges. Rolls-Royce, for example, has already announced the first flight of its all-electric “Spirit of Innovation” aircraft and has committed that by 2023 all of its Trent family engines will have been proven compatible with 100% SAF.

    The Rolls-Royce Trent, a family of high bypass turbofans produced by Rolls-Royce, has been able to help airline customers automatically update predicted maintenance deadlines for every life-limited component inside their engines by using AI forecasting and digital twins through IFS aviation maintenance software. This forms a key part of the Rolls-Royce Blue Data Thread strategy; a digital information thread connecting every Rolls-Royce-powered aircraft, every airline operation, every maintenance shop and every factory.

    More effective maintenance will also translate into sustainability benefits. As the aviation industry moves toward a greener future, digitalization and predictive maintenance are important elements for the engineering side of the industry. By reducing the need for maintenance interventions, part replacements and overhauls, the use of energy and resources in manufacturing is reduced, and the emissions footprint of part and engine logistics is minimized.

    Turn to Tech to Sustain Green Pledges

    These are just three industries where technology is playing a pivotal role in achieving ESG goals. The case is clear: Sustainability initiatives can be accelerated by here-and-now technology such as IoT, AI, cloud deployments and more, not space age or future–focused solutions. The link between meeting customer demands, fulfilling environmental goals and greater profitability has never been closer. Technology will be a strategic business enabler to achieve all three.

  • Why Developer-First is the Future of AppSec

    Why Developer-First is the Future of AppSec

    DevOps culture and rapid cloud adoption mean developers are shipping code faster than ever and, in many cases, security teams struggle to keep up. To avoid relegating security to afterthought status, organizations must shift left and adopt a developer-first approach to application security (AppSec).

    Organizations that depend on software development need a solution that accomplishes two essential things to adapt and survive: Risk-appropriate security measures and an even distribution of functions across the stack. First, risk-appropriate security measures must be applied to all software before it is delivered or deployed. Second, they must adopt processes that enable security functions to be distributed across the development stack in a way that will not slow down the pace of development.

    Just as the entire development process starts with developers, integrating security should also start with a developer-first approach. Developer-first AppSec is the future; here’s how organizations can evaluate tools that will help them adopt a developer-first approach.

    Why Developer-First is the Future

    Developers outnumber application security engineers by as many as 100 to one, and AppSec functions cannot scale if security practitioners are the only ones responsible for security. This imbalance suggests that organizational leaders must better distribute security ownership across the developer teams that own the software asset.

    As it stands today, many companies expect developers to build and deploy software faster than ever before. Security teams often can not keep pace with software development, and they become a roadblock to software delivery. To meet project development deadlines and their key performance indicators (KPIs), developers tend to leave security teams behind. They do not have the time or the incentive to slow down development because application security tools or processes are slow and cannot keep up.

    Security and developers are at cross-purposes in today’s software development model. They are pseudo-adversaries because AppSec teams know what it takes to make code secure, or at least they know how to find vulnerabilities. And, on the other hand, developers need to write code that works well and meets the sprint’s deadline.

    Friction Between Teams

    This growing problem creates friction between these two teams. It’s not that security teams don’t care about the organization’s need to produce quality software quickly or that developers don’t care about security. It’s just that each team is measured and incentivized to achieve opposing objectives. AppSec programs must create a developer-first approach to building software quickly and securely to combat this growing problem.

    It is not feasible for organizational leaders to provide security engineers with the entire business or environmental context behind software applications. In this sense, AppSec teams are working with limited vision. They may not see how the software fits into the organization’s big picture or understand its priorities.

    With limited contextual understanding, security teams necessarily rely on developers to make decisions about acceptable risks. If left to their own devices to view the world through a security-centric lens, AppSec teams could get bogged down—potentially spending too much time enforcing security measures that do not apply to the task at hand.

    Since developers are building the software and know what the services are designed to do, security engineers must defer to a developer-first approach so that decisions about security issues will align with the business context and acceptable levels of risk.

    Finding a Developer-First AppSec Platform

    Below is a condensed guide to help organization leaders evaluate potential AppSec platforms. These questions will help identify a solution that will enable the organization to build a developer-first security program.

    • Will the solution flood the developers and AppSec team with more and more results, or will this help them fix the essential gaps?
    • Will the solution provide context to help developers focus their limited time on security work that matters, or will it end up wasting time on things that may not even present a risk?
    • Will the solution help build security measures as guardrails to prevent security issues in the first place?
    • Is the solution flexible enough to enable building custom application security checks and policies in the SDLC?
    • Does the solution provide flexible ways of communicating actionable security information directly to developers in real-time within dev tools like source control systems, CI/CD platforms or engineering task management systems?

    There are an overwhelming number of application security solutions on the market today, most of which are designed to create security alerts about every conceivable threat regardless of the business context of the software being developed. More tools are then needed to manage the identified vulnerabilities.

    What This Future Will Look Like

    AppSec teams must recast themselves as security facilitators providing expertise for solving complex challenges and maintaining oversight of the developer teams’ security efforts. Developers should own tactical security tasks, but the AppSec team should continue to be the experts in making risk-based decisions and driving security accountability across the business.

    Inside many organizations, application security is only beginning to become integrated into developer workflows. This integration creates both opportunities and challenges. As organizations strive to make AppSec an enabler that aids developers in creating secure software quickly, developer-first AppSec programs let businesses make their digital transformation journey safer and faster.

  • 4 Ways to Uplevel Your Software Engineering Team

    4 Ways to Uplevel Your Software Engineering Team

    In my 20 years leading software development teams, I’ve witnessed the industry’s continuous growth alongside technology’s evolution. The only thing we know for certain is that the industry will continue to change and winning businesses will be those that build with change in mind, backed by effective, fast-moving software teams.

    This is the year we must focus on fine-tuning our DevOps processes and uplevel our teams, but where do we start?

    Below are four ways you can begin to transform your teams into engineering powerhouses, no matter how big or small or where they are in the world.

    1. Embrace New Delivery Models

    Remember when deployments were a big deal; a highly-anticipated event that often meant late nights? These days, many teams have managed to make deployments a non-event and are deploying any time of day. Those that haven’t adapted risk being left behind. The rate of deployments will only increase, so how teams handle this progression will be a deciding factor for success in an already competitive field.

    In 2022, teams should continuously evaluate their procedures as they push the boundaries of their tech stack. Navigating the complexity of the digital era—from massive datasets and machine learning to networks of third-party services—will force both developers and company leaders to embrace flexible tooling and processes to ultimately refine the risk/innovation tradeoff.

    2. Prioritize People and Culture

    While 2021’s Great Resignation saw many software professionals jumping ship in search of a fresh work environment, in 2022 we expect to see a Great Reshuffle. Realizing their new or current gig still may not be quite the right fit, engineers and developers will start looking for roles that are more in line with their long-term career and personal goals.

    Don’t fear this reshuffle. Instead, recognize it as an opportunity to build a strong and stable team. Be honest about what, exactly, the job entails and the hard and soft skills you’re looking for. Honesty throughout the recruitment process leads to a better match between employer and employee and also contributes to resilient company culture.

    3. Deploy Low-Code Solutions Strategically

    Pressure to get the highest productivity out of software development teams has led to the adoption of no-code and low-code solutions. But that means these tools are being used predominantly by people who already know how to code. The folks with big ideas who don’t actually want to be programmers remain unserved and untapped.

    Expect this disparity to soon lead to a split in the category of no-code and low-code solutions—those built specifically for optimizing developer teams, and those that can serve everyday creators. To really get the most out of your team, keep an eye on the low-code space and ensure the solution you use is the one that’s actually best suited for your goals.

    4. Build With Change Validation in Mind

    The growing adoption of cloud storage, service-oriented architectures, third-party API-based services and open source code (to name a few) makes modern software development monumentally complex.

    A way to manage this complexity is by pulling our focus away from the application itself and onto myriad sources of change that affect the application—a concept we can think of as change validation.

    Ultimately, change validation builds upon tried-and-true software best practices such as continuous integration, continuous delivery and release orchestration. Cloud-native architectures can be effective and scalable, but you need to have the right tools and systems in place to validate changes to your code at every step.

    In the past, the general consensus was that you shouldn’t test in production; you should just release and wait for the bug reports to tell you what’s wrong. But in the world of extensive software supply chains and cloud-native architectures, testing in production is the only way to truly know whether changes to your code are working as intended before releasing software to customers.

    In the new year, software developers will be of critical importance as organizations continue to expand on digital services and projects. Embracing new methods of software delivery, prioritizing people and culture and keeping an eye on how to best leverage automation tools like no-code/low-code and change validation will all help to transform your team for the better in 2022. This forward-looking approach and a willingness to reassess and pivot guarantees that your software engineering team will remain agile amidst a rapidly changing tech landscape.

  • Front-End Frameworks Enable Better Dev Collaboration

    Front-End Frameworks Enable Better Dev Collaboration

    The general public often thinks about software development in terms of a lone software developer hacking away tirelessly at their keyboard. Of course, that is an anachronism, at best. What is true is that collaboration among software engineers, especially with their colleagues in IT operations which evolved into DevOps, has become the norm for rolling out better code faster.

    We are on the cusp of the next big evolution as software development becomes more of a ‘team sport’ than ever before. Now, collaboration is extending beyond IT (developers and operations) to cross-functional areas across various business teams. Product development, marketing and others also are providing input and feedback into the software development process and, most significantly, becoming part of the process.

    Front-End Frameworks are Driving Collaboration

    Historically, software programming, including front-end programming, happened in local IDEs. However, the rise of modern front-end web frameworks has led to an entire class of developer tools that speed up the build process and allow applications to be deployed more quickly.

    There are a number of front-end frameworks that do this: Netlify, Vercel and Appsmith, an open source internal app builder, are three examples. These tools are getting widespread adoption, because, in a world where front ends are becoming more complex, they make things like hosting, deployment, authentication and serverless functions much simpler. The other reason for adoption is also because many of these tools are built on top of popular open source frameworks such as React, which already has a vast user base.

    This is enabling a new kind of collaboration that is unlocking a lot of value for all the stakeholders involved. Inspired by how Figma reshaped the design process by allowing real-time commenting back in 2016 or how Google’s suite allowed real-time editing, there is a similar phenomenon taking place over the last year in software engineering.

    Visual, Real-Time and On the App

    The most obviously striking feature is that collaboration is happening on the app (or the app prototype) and is becoming increasingly visual. Writing or editing code in the command line is great, but it doesn’t necessarily help the developer to visualize what is happening. Vercel’s Next.js Live, for example, allows teams to chat, draw and edit.

    collaboration

    This also means that collaboration is happening on the app instead of through tools like email, Slack and Jira, leading to targeted feedback without having to toggle between multiple tools.

    Collaboration and Feedback Loops Become More Inclusive

    While developers often collaborate at the code level, non-developers’ feedback is often given at the design level. This is more often the case for internal tools (or apps), which typically account for anywhere from 20% to 40% of engineering bandwidth in organizations.

    For example, Appsmith today has thousands of developers self-hosting and deploying internal applications for users who are often business or operational teams like support, sales and/or finance, for example. Often, these business users don’t even know who has built the application. Real-time commenting via front-end frameworks facilitates collaboration between software engineering teams and their business counterparts who can now communicate directly, provide feedback and collaborate with their engineering peers. This close collaboration empowers all parties, increases efficiency and saves significant time while improving the overall quality of the software and ensuring that it meets expectations.

    AppSmith

    In addition, non-engineers don’t need to familiarize themselves with a new tool like GitHub or go through a painful replication issue on Jira involving a variety of screenshots or screen recordings. Sharing feedback can be done much more easily.

    Better Version Control and Feedback

    For developers, having the ability to visualize a particular branch of an application and give detailed feedback on it and then track it on GitHub or GitLab speeds up the development cycle. Netlify, for example, pioneered this when it launched Deploy Previews earlier this year. Netlify takes this feedback and integrates it into project management tools like Jira, Trello and many others in addition to GitHub and GitLab.

    collaboration version control

    We are seeing other companies, like Sturdy, building on this much-needed trend of real-time collaboration in app development.

    Collaboration is the Trend

    Great software is the story of teams expanding collaboration beyond developers and there is a lot of good tooling available to help achieve that. This trend should continue to gain traction in the years to come because it taps into a number of other underlying trends in the software development space.

    First, the explosion of alternatives in the backend-as-a-service space, in which Heroku and Firebase were early pioneers, means BaaS is embraced by many more organizations for a variety of use cases. This trend speeds up development because they present a much more tightly integrated ecosystem of services and organizations don’t have to worry about deployment, hosting, content delivery network (CDN) and/or authentication themselves, for instance.

    Second, the proliferation of APIs is driving the emergence of more complex applications built on a variety of data sources. Everything is connected to everything. Of course, this also means that a lot more data is available to support decision-making, and this leads to many different kinds of applications being created both for external as well as internal purposes.

    And finally, the larger low-code/no-code movement is creating millions of new citizen developers and blurring the boundaries between who is and isn’t a developer.

    Summary

    DevOps marked the start of the evolution of software development into a team sport, and collaboration is now accelerating beyond the boundaries of IT. Like DevOps, the result of this collaboration in the software development process will be better software that propels businesses forward created faster than ever before.

  • App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    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 Open App Markets Act polls well among devs, Germany fines a website for using Google Fonts, and the New York Times buys Wordle for an unfeasible sum.

    1. Antitrust Bill Would Open Up App Stores

    First up this week: The Open App Markets Act seems like a big hit with developers. In a survey, more then 80% wanted lawmakers to pass this bipartisan Senate bill.

    Analysis: But 30% of nothing is nothing

    One of devs’ biggest complaints is Apple’s 30% cut of all revenue—including in-app purchases. Many devs have also experienced random rejections of submissions to the stores. And these seem to be the main driving forces behind devs’ calls to tear down any walls around the gardens. But they should be careful what they wish for—users might not see it the same way.

    Karl Evers-Hillstrom: 8 in 10 app developers back measure to rein in Google, Apple

    The Coalition for App Fairness, [an] industry group for app developers, is pushing Congress to pass the Open App Markets Act. [The] bipartisan Senate bill … would block app stores from favoring their own in-house apps in searches, requiring developers to use their payment systems and preventing users from downloading apps from third-party stores.
    …
    Developers surveyed … complained about exorbitant fees … and expressed how they’d experienced difficulty getting their apps featured or accepted by app stores. Just 13 percent of app developers surveyed oppose the bill. … The margin of error is plus or minus 7.11 percentage points.
    …
    The proposal, co-sponsored by Sens. Amy Klobuchar (D-Minn.), Richard Blumenthal (D-Conn.) and Marsha Blackburn (R-Tenn.), is scheduled for a committee markup this week. The CEOs of Apple and Google have personally lobbied lawmakers to abandon [such] antitrust legislation.


    Wouldn’t that just kill the proverbial golden goose? No, says this Anonymous Coward:

    The only reason Apple has any success with the iPhone is because developers write apps for it, it’s no different to Windows in that regard. … If Apple’s app store is so good then everybody from developers to end users will continue to use it and nobody will use third party app stores.
    …
    Obviously there is a clear profit motive to exclude any competition in the app store space. But I don’t understand how people can claim that Apple makes great products and simultaneously argue that they couldn’t possibly survive competition on the platform.


    But Dr. Edith Müdyk—@BabyHueby—doesn’t sound hopeful this will go anywhere:

    Too bad policy isn’t dictated by public opinion.

    2. German Court Fines Site for Using Google Fonts Without Consent

    Did you know you need to get permission from a European user before you remote-load a Google Font? You do now.

    Analysis: Schrems II comes home to roost

    More GDPR popups ahoy! A German court has “clarified” that websites and apps should obtain informed consent before loading content—if loading it would reveal a user’s IP address to a third party. Luckily, the fine was only $110—this time, but if the perp was to do it again, the court threatened 2500× that amount.

    Thomas Claburn: Website fined by German court for leaking visitor’s IP address via Google Fonts

    A German court fined an unidentified website €100 ($110) … for violating EU privacy law by importing a Google-hosted web font. [It] passed the unidentified plaintiff’s IP address to Google without authorization and without a legitimate reason for doing so. And that violates … GDPR.
    …
    The website could have avoided this drama by self-hosting the font. … The ruling explicitly cites this possibility to assert that relying on Google-hosted Google Fonts is not defensible under the law.
    …
    The ruling directs the website to stop providing IP addresses to Google and threatens … a fine of €250,000 for each violation, or up to six months in prison, for continued improper use of Google Fonts. … These data privacy judgments … reflect the consequences of the EU Court of Justice’s 2020 decision to strike down the Privacy Shield data protection arrangements that had previously allowed US companies to exchange data with European partners under “Standard Contract Clauses.”


    Isn’t that ridiculous? And surely not the intention of GDPR? Aristos Mazer very much disagrees:

    This is very much the intended consequence, with a lot of analysis going into this regulation. … Even if that means redesigning foundations of the network.
    …
    Forcing sites to stop transferring data in any way shape or form to Google, Apple, Microsoft, Facebook, etc. … is exactly the goal. [It’s been] repeatedly validated by polls of EU citizens.


    And indeed, the point is to get “informed consent.” Here’s Hans Neeson-Bumpsadese:

    “To proceed beyond this point … your IP address needs to be shared with a 3rd party.” Would they click on that? … I know at least one person who would read that as, “If I click that link then you will tell people where I live.” (I know because they got a pop-up like that once, and phoned me in a state of mild agitation.)

    3. Wordle Sold to NYT for Over $1M

    Josh Wardle, a Welsh developer living in New York, has sold this winter’s social gaming hit to his state’s namesake newspaper of record. The New York Times thinks it’ll be a useful addition to its Games section. But the price tag is incredible.

    Analysis: Nice payday for Josh

    How much? Hard to see how the Times is going to make money out of this. Tomorrow’s word must be: NOROI.

    Alexis Benveniste: The Sudden Rise of Wordle

    In less than six months, Wordle has gone from a gift to a viral sensation, to … part of The New York Times. … Josh Wardle, a software engineer in Brooklyn, created the game as a gift for his partner … and it exploded in popularity.
    …
    Nearly two months later, 300,000 people played it. … The buzz around the game can be attributed to the spoiler-free scoring grid that allows players to share their Wordle wins across social media.
    …
    Wordle was acquired for an undisclosed price in the low seven figures.


    In other words, north of $1 million. Not bad for a quick, one-dev hack by Josh Wardle:

    The game has gotten bigger than I ever imagined (which I suppose isn’t that much of a feat, given I made the game for an audience of one). … I feel so grateful for the personal stories some of you have shared with me.
    …
    [But] I’d be lying if I said this hasn’t been a little overwhelming. [So] I am incredibly pleased to announce that I’ve reached an agreement with The New York Times. … I’m thrilled they will be stewards of the game.


    But “RIP Wordle,” mourns _xeno_, seemingly speaking for many:

    It’s about to be bogged down with trackers, and then later, ads. … A paywall is almost certainly on its way—The New York Times very carefully said it would “initially remain free.” … Not surprisingly, there are already plenty of clones. … There’s no way for the New York Times to make money off this.

    The Moral of the Story: No disguise will hide one’s true character.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Masahiro Miyagi (via Unsplash; leveled and cropped)

  • DevOps for Salesforce: CI/CD Challenges

    DevOps for Salesforce: CI/CD Challenges

    DevOps encompasses a wide variety of technical and social practices for improving the development, delivery and operation of IT systems. Salesforce has become more than a CRM system; it evolved into a full-featured ecosystem and a low-code platform that made development far simpler and more approachable than traditional code-based platforms. Cross-functional teams build on Salesforce to create custom apps and integrations with other enterprises systems without requiring the rigorous approaches that are common with traditional technologies like Java.

    Now, DevOps for Salesforce has emerged to enable teams to build applications faster. And as teams have built more and more customizations onto the Salesforce platform, the level of complexity has exploded. DevOps has emerged as a critical capability for teams to bring this complexity under control.

    The Primary Challenge of Deployments

    The primary challenge that most Salesforce teams face is deployments. Deployments on Salesforce are not just a matter of moving files, they require sophisticated management of thousands of XML files and careful management of dependencies. A number of commercial companies have appeared to help manage the Salesforce development life cycle, and the Salesforce development experience (DX) initiative has unlocked vastly more possibilities for teams to automate existing processes and adopt new workflows.

    The need for more structured and rigorous approaches to Salesforce development has increased the need for teams to learn from traditional software development and DevOps teams and understand how traditional techniques like modularization and continuous integration can be adapted to the Salesforce platform. Technology and knowledge transfer from the broader DevOps community to the Salesforce community remains an active area of exploration.

    Working in Parallel

    It was the adoption of continuous integration by the extreme programming (XP) community in the 1990s that drove intense interest in the need for automated testing, especially unit testing. This allows teams to create exact copies of each other’s work and develop in parallel. Working in parallel allows for far faster innovation since work doesn’t have to be precisely sequenced. 

    But there’s a cost to working in parallel; these workstreams eventually need to be integrated into a cohesive whole. Software projects following a “waterfall” methodology may delay integration until near the end of the project. But these parallel work streams diverge naturally over time, meaning that integration can take months and require enormous amounts of rework.

    Continuous Delivery: A Distinct Practice

    Continuous integration (CI) avoids this issue by merging work early and often (at least daily). “If it hurts, do it more frequently,” is a mantra in the CI world, where the challenge is to resolve conflicts in small batches rather than letting them accumulate.

    CI creates a constant risk of failure for software, since teams working on one part of the system may be making changes to shared components that can cause other teams’ code to fail. Automated testing provides a layer of protection by allowing functionality to be checked and rechecked thousands of times with minimal human intervention. Creating automated tests requires more effort than executing a manual test, but the cost of re-running each test becomes negligible. Thus, automated testing is a perfect solution for high-velocity teams who need fast and ongoing ways to ensure they are not regressing as they build new capabilities. 

    Continuous delivery (CD) is a distinct practice that’s often mentioned in the same breath as CI. Continuous delivery was popularized by the 2010 book of the same name by Jez Humble and Dave Farley. The practice of CD extends the idea of CI by aiming to deploy code to production in small batches on a regular basis; ideally at least daily. Whereas CI addresses the risks of developing in parallel, CD addresses the risks of delaying feedback from end users.

    Software is built to solve specific problems. But each attempt at a solution by developers is a hypothesis that needs to be tested and confirmed. Only the people who actually experience that problem can tell developers whether these solutions are sufficient. So developers must get fast feedback from end users to have confidence in what they’ve built. Teams that neglect this practice are operating on assumptions and optimism; the longer they delay delivery the more the risks of those assumptions compound. Poor adoption and user experience is to be expected when teams don’t practice continuous delivery.

    Increasing Pressure

    CI creates added pressure to test quickly, CD increases that pressure significantly. Delivering small batches of changes reduces the risk of each change and makes them faster and easier to roll back. But by definition, we are changing production systems that may be used by thousands or millions of people each day. A failure caused by CI may waste a few hours of a developer’s time and delay delivery of a change. But a failure caused by CD can prevent thousands of people from doing their jobs, corrupt production data, expose security vulnerabilities and worse.

    When developers integrate their work in CI, the goal is to run a fast set of tests that confirms nothing major has broken. But work being delivered to production needs to go through a battery of comprehensive tests to ensure it meets all functional and structural requirements. In a waterfall-style project, pre-release testing may involve scores of testers working for months. In continuous delivery, teams must be able to execute tests at every level of the system and have robust confidence that no failures have occurred.

    Comprehensive testing requires testing the user interface, testing processes that span multiple systems, loading and confirming data using APIs, security testing and more. Continuous delivery has driven the need for automated testing to new levels and led to entirely new approaches like canary deployments. Canary deployments are a form of shift-right testing where a feature is initially delivered to a small subset of end users to check for issues before rolling it out to everyone.

    The Essence of Lean

    It’s often said that the main driver of success in DevOps is culture. The acronym CALMS is used to summarize the five aspects of DevOps: Culture, automation, lean, measurement and sharing.

    Culture refers primarily to creating a culture of continuous learning and experimentation. The practices described above are not formulaic and require a growth mindset and a culture that prioritizes psychological safety and information flow.

    Automation is the aspect of DevOps most commonly emphasized (including in what’s been written here). Automation enables dramatic efficiencies and is the central miracle of technology, but automation is not a panacea without addressing these other aspects of DevOps.

    Lean refers to the manufacturing practices pioneered in the 1930s at Toyota and further developed and built upon in the late 1980s and 1990s. The essence of lean is to do more with less by understanding and optimizing the value stream by which work is actually performed.

    Measurement refers to the importance of taking a data-driven approach to optimizations. Measurement provides teams with a way to gauge whether process improvements are effective or not.

    Finally, sharing refers to the importance of sharing information, practices and resources between individuals, teams and organizations.

  • Securing Software with Intelligent Pipelines

    Securing Software with Intelligent Pipelines

    One of the biggest cybersecurity risks involves vulnerabilities in the application layer. After all, the best firewall is useless if the web application itself is vulnerable. Many companies have worked to mitigate these risks by investing in their AppSec programs. According to a recent whitepaper written by ESG (commissioned by Synopsys), 71% of companies surveyed now use AppSec tools for more than half of their software projects. Notably, over two-thirds of companies already use 11 or more automated application security testing (AST) tools, such as SAST, DAST, IAST, fuzz testing and container scanning solutions.

    This is due, at least in part, to the fact that tool manufacturers have now made their products “DevOps-ready” and support suitable integrations with CI/CD pipelines. This makes it tempting to simply let AppSec scanners run in the pipelines, but that can introduce other problems.

    Problems with AppSec in CI/CD Pipelines

    Too many results: Developers can be inundated with findings, yet only a small percentage are likely to pose such a high risk that they need to be fixed immediately. But the prioritization guidelines are often formulated in separate documents and are ambiguous.

    Development pipelines are slowed down: Build pipelines often run at frequent intervals; every second to every minute. Scans with AppSec tools may take several minutes or even hours.

    Manual AppSec activities are left out: Not all AppSec activities can be automated, such as architecture risk analyses, threat models and penetration tests. Nevertheless, these are an essential part of the AppSec strategy.

    Intelligent pipelines (i.e., intelligent, purpose-optimized automation and orchestration of the various AppSec tools and activities) are ideal for overcoming this challenge. Combined with the consolidation of scan results, a new category of solutions has emerged here, which Gartner dubbed application security orchestration and correlation, or ASOC for short, in 2019.

    How Pipelines Become Intelligent

    The “intelligence” lies in deciding which tools need to run at what time and what to do based on the results. So instead of scanning the entire codebase with AppSec tools at every commit, it dynamically decides which scanner needs to run and to what extent. This decision can take into account various parameters such as the scope of the actual code change, the risk profile of the application or the development stage of the software.

    The risk profile of the application should also be considered. Web applications that are accessible from the internet and process sensitive data pose a greater security risk than an internal tool for generating documentation. Such risk profiles usually emerge from prior architectural risk analyses and threat models.

    Furthermore, the scope of AppSec testing should be appropriate to the development stage of the application. Individual commits of a feature branch should be checked mainly by static code analysis for passwords and API tokens contained in the code and compliance with coding guidelines, such as SEI CERT, to support rapid development. Later on, during the merge request into the main branch, more extensive scans should be added, including deeper data flow analyses, which then detect cross-site scripting or SQL injection attacks. A longer runtime can be accepted here since such merge requests usually have to be approved according to the dual control principle.

    Code Security Policies

    The core of intelligent pipelines lies in individual guidelines or policies. These define when specific AppSec activities are executed. Additionally, these policies describe how to proceed with the combined results (e.g., whether the code may be integrated into the master branch or the web application may go live).

    The policies are described in a configuration file; this is policy–as-code. Just as with other as-code methods, this enables or improves uniqueness, reproducibility and automation. Simple policies can be created according to the “If this, then that” principle. For example, a software composition analysis (SCA) scan can be triggered when either the project file changes (package.json, go.mod, pom.xml, etc.) or new files or directories are added, but not when only existing source code files are changed.

    Conclusion

    Whether with or without orchestration tools, anyone who wants to make their software more secure must inevitably consider which AppSec activities make sense at what time. In other words: The right scan at the right time. Furthermore, it should be determined how to proceed with the results before ordering or even automating a scan. To do this, you need to understand what the greatest risks are and how to protect the software from those risks.

    Intelligent pipelines help to implement and, above all, automate an AppSec strategy. A corresponding strategy is a prerequisite. But even (or especially) without a clear strategy, it makes sense to look at the architecture of an intelligent pipeline, as this both encourages collaboration between development, AppSec and DevOps teams and raises the right questions that lead to a successful AppSec strategy.

  • Innovation With Software Architectural Excellence

    Innovation With Software Architectural Excellence

    Software architecture plays an irreplaceable role in enabling businesses to deliver value efficiently. This is evident in how digital natives have been challenging incumbents and forcing them to rapidly digitize and transform how they operate and innovate. Accordingly, achieving architectural excellence is a continuous process of efficient implementation, advanced planning, and executive leadership engagement. Furthermore, it’s essential to recognize that software architectural strategies and planning shouldn’t be limited to IT. Enabling collaboration between IT and business leaders is necessary as software architecture plays a key role in delivering value, making processes robust, and tackling the next wave of changes in value creation and delivery.

    The Goal of a Good Software Architecture

    A good software architecture facilitates the ongoing business processes function robustly and ensures business capabilities are competitive against threatening challenges. Beyond this, the software architecture should also become the fundamental aspect of driving the next waves of business changes—whether they are processes, models, or innovative products and features. These changes result from competitive forces increasing digitization, transformation, and ecosystem-based consolidation, making change the overarching constant in various business aspects. Accordingly, conventionally viewing a software architecture at a limited software or product level doesn’t work as well as it used to. The practice of viewing software architecture at the business and ecosystem-level gains even more emphasis as digitization and innovation make businesses and ecosystems digitally intertwined in how they interact.

    The following fundamental aspects describe how to innovate with architectural excellence:

    Security and Privacy

    Customers are increasingly becoming wary of how their data is handled and protected—and are even reluctant to do business if an organization doesn’t have clear policies on how it protects and handles customer data. On the other hand, regulators are constantly improving their compliance requirements to protect customers. This landscape is changing at different rates across multiple countries, posing challenges and equally creating opportunities for fast adapters. All of this implies that businesses need to ethically manage customer data along with protecting against the constantly evolving threat landscape. To satisfy this need, it is necessary to revise the existing software architecture and involve senior executives in making critical decisions in this respect. Moreover, architectural planning cycles should come down to a few months—instead of years. This is key to building and implementing innovative solutions rapidly to tackle changing regulatory landscape and customer expectations.

    Satisfy User Needs

    Since 2008, the smartphone has been changing customers’ experiences and expectations. Digital disruptors are continually challenging incumbents and threatening their survival. In this paradigm shift, businesses should understand their customers more deeply, quickly adapt their business models and introduce new products to fulfill customer needs. It requires architectural agility that offers the flexibility to innovate business models in shorter cycles and improve them faster with customer feedback. This also means keeping a long-term view towards software architecture planning and strategy development that enables seamless innovation and eliminates process and performance bottlenecks. In this view, software architecture improvements and decisions should align with business objectives and strengthen business capabilities, not just the number of implementations or technical solutions the IT has delivered.

    Empower Developers

    Today, more and more businesses need developers to help them digitize and transform. Accordingly, empowering developers is essential, and software architecture is the fundamental way to help them drive innovation and build critical business capabilities. Developer empowerment is usually measured in terms of developer velocity — it defines how enabled developers are to be agile and how well their talent is utilized. To improve developer velocity, provide them with a well-defined software architecture to focus on quality and consistent development. Also, the software architecture must have scope for customization so that developers can utilize it to its full potential.

    While the above describes the overarching approach, the following sections detail the fundamental aspects of achieving innovation with architectural excellence.

    Scalability

    The software architecture should support scaling applications seamlessly on-demand to accommodate spikes in user growth and scale back to save operational costs. Accordingly, this approach requires deploying your application in the cloud while ensuring not just the underlying infrastructure but also the multiple components in your entire system scale without friction or intervention. High performance should accompany this to ensure customer satisfaction and deliver a superior experience. This means that your system should perform ideally at any scale at any time.

    Portability

    Can the system itself or components of it be deployed in any cloud platform—public, private or hybrid cloud? How much does it cost to move in terms of time, effort, and cost? In a world of hyperscale cloud providers and cutting-edge cloud services, a company’s IT ecosystem shouldn’t be locked into one platform or vendor but should utilize the best available services and technologies currently—that are also future-ready to improve performance and optimize overall costs.

    Compliance

    Businesses should develop a compliance framework that aligns people, processes and strategies with regulatory requirements to ensure compliance and avoid non-compliance risks. Also, the framework should be work-in-progress to accommodate upcoming changes from regulators across the board.

    Maintainability

    Similar to the source code of software components, software architecture should be easily maintainable—meaning that the software architecture shouldn’t introduce bottlenecks when modifying and improving it.

    Maintainability issues could take many forms: is the software architecture outdated for the current technical and business landscape? Is it using legacy versions that are incompatible when other components and dependencies are updated? Ensuring the software architecture’s maintainability helps facilitate innovation and move at a competitive pace. If at all unsure where to start improving or redefining a software architecture, start with maintainability.

    Cost

    IT is often under constant scrutiny to justify its expenditure, and it is complicated to measure IT’s meaningful contribution to the business outcomes. As a result, IT constantly faces the risk of budget cuts and challenges in optimizing costs. Typically, the software architecture is let to grow organically, leading to duplication of system and efforts and inconsistent data across systems. To overcome this, control the software architecture on an ongoing basis, which, in turn, allows for more predictable cost-control.

    In this fast-changing landscape of digital, businesses should maintain flexible architectures that facilitate innovation and continually improve the software architecture using agile methodologies to gain a competitive advantage in the business capabilities. This practice is much needed, especially when digital disruptors are increasingly threatening to take it all—leaving laggards behind.

  • EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

    EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

    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: iMessage lock-in lessons, attrition-rate fixes, and more on Mozilla.

    1. ‘Never Date a Green Texter’

    First up this week: The weekend story getting the technorati chattering was about how Apple iMessage denizens pour scorn on Android users—identifying them by their “icky” green chat bubbles. An iPhone user’s message gets a “proper” blue background, y’see.

    Amusing though the story was, the writer seemed to be hell-bent on proving some sort of Apple C-suite-led “conspiracy to lock in.” The reality is far more mundane—but it teaches important lessons for DevOps.

    Analysis: Unintended consequences FTW

    Could your DevOps team make a trivial engineering decision that pays unexpected dividends? While lock-in might be distasteful, seemingly irrelevant design or technical choices can have huge ramifications with users.

    Tim Higgins: Why Apple’s iMessage Is Winning

    [The] pressure to be a part of the blue text group is the product of decisions by Apple executives starting years ago that have … helped to cement the iPhone’s dominance among young smartphone users. [It] encourages people to pay the premium … and remain loyal to its brand.
    …
    Teens and college students said they dread the ostracism that comes with a green text. The social pressure is palpable. … Jeremy Cangiano, who just finished up his MBA, … tried to cash in on it last year by selling his own merchandise that touted, “Never Date a Green Texter.”
    …
    The blue iMessage bubble was born out of a simple engineering need, according to Justin Santamaria, a former Apple engineer who worked on the original feature. … The idea that it would keep users locked in to using Apple devices wasn’t even part of the conversation at the time, he said.


    And then the other shoe dropped—via Ron Amadeo:

    Google took to Twitter this weekend to complain that iMessage is just too darn influential with today’s kids. … The company is hoping this public-shaming campaign will get Apple to change its mind. [But it] probably has the least credibility of any tech company [because it] has released 13 half-hearted messaging products since iMessage launched in 2011.
    …
    Google … seems to have learned nothing from its years of messaging failure. Today … the situation is an incredible mess, and no single Google product is as good as Hangouts was in 2015.


    Ouch. With a sociological perspective, here’s Christina “filmgirlcw” Warren:

    iMessage is incredibly popular with certain demographics. … It’s an in-group signifier—the way teens have always had in-group signifiers (when I was in high school, it was AIM, a Nokia, and wearing Abercrombie). … It’s always fascinating for me to go to other countries and see a ton of iPhone users not using iMessage but something else because that app has become the in-group signifier. … Every teen I know uses Discord more than they use almost anything else.
    …
    It isn’t about lock-in or regulation or technology. It’s about fashion.

    2. How’s your Attrition Rate?

    A study published this week says DevOps orgs and other internet companies rank third for attrition in the 38 industries surveyed. And if you lump that category together with “enterprise software,” it would be in clear first place.

    Analysis: We’re #1! Oh, wait …

    But some companies get this right—how can you be one of them? Culture, innovation, recognition and remote work. It’s definitely not only about pay.

    Donald Sull, Charles Sull and Ben Zweig report their fascinating study: Toxic Culture Is Driving the Great Resignation

    Between April and September 2021, more than 24 million American employees left their jobs. [But] while resignation rates are high on average, they are not uniform … from less than 2% to more than 30%. … More-innovative companies … are experiencing higher attrition rates than their more staid competitors.
    …
    Pay has only a moderate impact on employee turnover. … A toxic corporate culture is by far the strongest predictor of … attrition and is 10 times more important than compensation. … Job insecurity and reorganizations are important predictors of how employees rate a company’s overall culture. … But it is surprising that … the more positively employees talked about innovation at their company, the more likely they were to quit. … Employees are more likely to leave companies that fail to distinguish between high performers and laggards [or] that tolerate underperformance.
    …
    Our analysis identified … actions that managers can take … to reduce attrition. … Lateral career opportunities are 12 times more predictive of employee retention than promotions [and] 2.5 times more powerful [than] compensation. … Company-organized social events, including happy hours, team-building excursions [and] potluck dinners … are a key element of a healthy corporate culture. … Unsurprisingly, when employees discussed remote work options in more positive terms, they were less likely to quit.


    And the flipside of resignation? Hiring replacements. Let’s turn to the equilibrium of Nash Reilly:

    It’s only gotten harder in recent months [and] I think I know why. … You need to offer engineers some combination of these three things to pique their interest: Cool stuff to work on, smart people to work with [and] some degree of repeatability.
    …
    You can’t really prove to an engineer that you can give them things like good management, minimal churn, and decision making authority [so] let them talk to your employees. … Also, figure out a way to let your team “backchannel” to the candidate. [If] your product is not that cool … play up the things you can offer them: smart coworkers, and a stable working environment. … You can afford to be honest about what it is that you do offer to a candidate, [so] pitch them the truth: that you want to do good work, sustainably, for as long as you can—ideally with them on your team.


    Perhaps the smart money is already skating to where the puck will be? Here’s echelon:

    Engineering salaries are … one of the biggest expenses. … Companies love that they can now hire remotely and pay adjusted cost of living. They’ll hire as many workers in middle America as they can, and once enough of the workforce is concentrated outside of expensive cities, you’ll see them stop hiring in SF and NY entirely. [And] startup capital is already beginning to shift to … emerging markets. Employment will eventually head there too.
    …
    Make your money now while the iron is still hot.

    3. Say Something Nice About Firefox

    After accusing Mozilla of jumping the shark last week, perhaps I owe the Firefox folks a positive inclusion this time? The release notes for Firefox 96 certainly sound good.

    Analysis: Improved sound; better perf; stronger anti-CSRF

    Outside the Apple walled garden, Firefox is about the only non-Chromium browser. A browser monoculture can’t be a good thing for anyone—not DevOps nor users.

    Michael Gariffo: Firefox 96 update focuses on noise improvements, main thread efficiency

    On the desktop side of things, Mozilla’s latest release made “significant improvements” to the browser’s built-in [sound] noise suppression and auto-gain-control features. These improvements are aimed at web-based video chat users.
    …
    The second tentpole feature in version 96 focuses on reducing main-thread load, which should help the browser function better on older, slower, or congested systems. [And] a new enforcement setting for cookies … will, by default, apply the “Same-Site=lax” policy. Mozilla claims this will help better defend users against Cross-Site Request Forgery (CSRF) attacks.
    …
    Mozilla also acknowledged that it is working on correcting the performance of detached videos being played in full screen on macOS devices. … No timeframe was mentioned for when it might be available again.


    Okay. Sounds good. But not to Tetch:

    Never mind all that fancy stuff. … Any reduction in crashes?
    …
    FF crashes for me several times a month. … I always take the trouble to fill in the “What were you doing immediately before the crash?” section of the crash submission dialog, and never hear another thing.


    But more efficiency on the main thread? Tell me more. ksec:

    Such an important detail that deserves at least few more sentences of marketing message or explanation. But the whole release note just feels like they couldn’t be bothered anymore.

    The Moral of the Story: A weasel wishing Happy New Year to a chicken harbors no good intention.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Moritz Knöringer (via Unsplash)

  • Theranos’s Holmes VC Reverb | 5G C-Band Marches On | Mozilla Jumps Shark

    Theranos’s Holmes VC Reverb | 5G C-Band Marches On | Mozilla Jumps Shark

    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 conviction of Theranos CEO Elizabeth Holmes leads to greater scrutiny of startups, higher-frequency 5G NR is creeping towards reality, and Mozilla gets criticized for promoting climate-harming scams.

    1. Holmes Case Causes Valley Rethink?

    First up this week: Elizabeth Holmes has been found guilty of defrauding Theranos investors. But how will the affair change Silicon Valley’s startup-and-funding culture?

    Analysis: Don’t fake it—just make it.

    This could be a seminal moment, causing investors to look more closely at startup founders and their outlandish promises. On the other hand, key Theranos investors—e.g., Murdoch, Cox, DeVoss—hardly fit the mold of Silicon Valley VCs.

    David Streitfeld: The Epic Rise and Fall

    F. Scott Fitzgerald’s creation … Jay Gatsby … was a bootlegger [and] sold fake bonds. Ms. Holmes chose Silicon Valley, the last and greatest of all human dreams. [She] was a natural salesperson, as good at bending reality as Steve Jobs himself.
    …
    She and her deputy and boyfriend, Ramesh Balwani … thought they could brazen it out in the Silicon Valley tradition until they had something that actually worked. [But] the verdict signaled the end of an era. In Silicon Valley, where the line between talk and achievement is often vague, there is finally a limit. … It is an epic rise and fall that will be chewed over in the coffee shops and juice bars of Palo Alto, Calif., until the tech industry departs [for] off-world colonies.
    …
    So where does this conviction leave … her investors and former fans? Ripe for the next huckster that comes along, probably. Some Silicon Valley promises are so sweet we just can’t get enough of them. Immortality. Crypto. Flying cars. Mars. Digital harmony. Wealth beyond compare.


    Think different, thinks DeanonymizedCoward:

    [There’s a] fine line between bombastic marketing spam, “fake it ’til you make it” pitches, and outright fraud. … The first is repugnant and sometimes unethical, but generally legal.
    …
    [But] If your product requires bull**** to get funded—even if it ultimately works—you’re a fraud. … Regulatory reforms … and a sort of corporate death penalty … can fix a lot of this by making it less financially practical to engage in ****ty behavior.


    Who else is to blame? Ask DS999:

    I am sure some of her investors didn’t really care whether it worked. They just wanted to get in early, ride the hype train up, and sell before actual results mattered.

    2. FAA and 5G Carriers Kiss and Make Up

    Higher-frequency 5G NR is creeping towards reality in the U.S., thanks to the FAA backing down. After the aviation regulator had vetoed C-band deployment—based on precious little evidence—it looks like as much as 280 MHz of extra spectrum is now ready to switch on.

    Analysis: Nomadic DevOps gets more bandwidth

    While band 77 is nowhere near the much-vaunted “FR2” extremely high frequency bands, this is a useful chunk of extra spectrum for mobile and nomadic apps. Next stop: ubiquitous Ka-band.

    Jon Brodkin: FAA agrees not to seek any more 5G delays

    The Federal Aviation Administration tentatively agreed not to seek any more 5G delays from AT&T and Verizon, potentially ending a battle over the aviation industry’s unproven claim that 5G … will interfere with airplane altimeters. [Their] C-Band spectrum licenses are for the frequencies from 3.7 GHz to 3.98 GHz.
    …
    The deal incorporates voluntary commitments that AT&T and Verizon previously made, including “C-Band radio exclusion zones” around airports for six months. [They] modeled the exclusion zones after those used in France, which are 910×2100 meters.
    …
    Assuming there are no further problems, AT&T and Verizon would be able to use their spectrum licenses without extra restrictions after July 5. … President Biden applauded the agreement … calling it “a significant step in the right direction.”


    In summary? Here’s Dieter Bohn:

    The agency in charge of airplanes is mad about wireless things. But the agency in charge of wireless things and the companies that make them lost a game of chicken.
    …
    GREAT JOB AMERICA. … I always said I wanted Internet Service Providers to be Dumb Pipes, but I never expected them to be this dumb.


    Has anyone read the FAA’s detailed report? bburdge has:

    I can see why the FAA is backing down here now, it only makes sense when your key report could be paraphrased as: “We got a couple grad students to run some basic model comparisons … using altimeter data from the aviation industry (with a proven track record of lying to us) and then went golfing for eight months before publishing … but didn’t bother … to actually test anything.”

    3. Mozilla Forgets its Values

    Firefox custodian, the Mozilla Foundation, has angered many by promoting a “grossly irresponsible” “Ponzi scheme” that harms the environment. What is this awful thing? I hear you ask. It’s cryptocurrency.

    Analysis: Imaginary money is bad—is this the last straw for Mozilla?

    Less than a year ago, Mozilla said it wants to be carbon-neutral, but it’s already reneged on that promise: Distributed proof-of-work systems require … well, work. And that work uses ridiculous amounts of energy per DeFi transaction. Electricity production is a zero-sum game, so cryptocurrencies and NFTs cause climate change by emitting ridiculous amounts of CO₂e.

    Liam Proven: Mozilla founder blasts browser maker

    A few days ago, Mozilla Foundation invited netizens on Twitter to send in cryptocurrency donations. … This move by the Firefox browser maker rapidly drew criticism.
    …
    As recently as September, Moz’s web-standards lead Tantek Çelik slammed cryptocurrencies as being unsustainable, stating: “[They] are harmful for sustainability. … Their energy requirements grow without any discernible upper bound, which is grossly irresponsible given the global environmental crisis.”
    …
    Mozilla has accepted crypto-coin donations for years, perhaps as part of its long-ongoing efforts to alienate its own users: It’s only the payment provider that changed.


    Chief among critics was Jamie “jwz” Zawinski:

    I founded Mozilla and I’m here to say **** you and **** this. Everyone involved in the project should be witheringly ashamed of this decision to partner with planet-incinerating Ponzi grifters.
    …
    Stop saying you were promised flying cars. Unless you were born in 1935, you weren’t promised flying cars, you were promised a cyberpunk corporate dystopia.


    It’s a shark-jump moment thinks Jeremy Keith:

    The most convincing argument I’ve heard yet for switching away from Firefox as my main browser comes from Mozilla. I wasn’t expecting that plot twist.

    The Moral of the Story: What is safety to one is not always safety to another.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Benjamin Hayward (via Unsplash)