Tag: engineering

How Will China’s Quantum Advances Change Internet Security?

How Will China’s Quantum Advances Change Internet Security?

Image Generated with Dalle 3

Introduction:

Chinese scientists have recently announced that they have successfully cracked military-grade encryption using a quantum computer with 372 qubits, a significant achievement that underscores the rapid evolution of quantum technology. This breakthrough has sparked concerns across global cybersecurity communities as RSA-2048 encryption—a widely regarded standard—was reportedly compromised. However, while this development signifies an important leap forward in quantum capabilities, its immediate implications are nuanced, particularly for everyday encryption protocols.

Drawing on technical insights from recent papers and analyses, this article delves deeper into the technological aspects of the breakthrough and explores why, despite this milestone, quantum computing still has limitations that prevent it from immediately threatening personal and business-level encryption.

The Quantum Breakthrough: Factoring RSA-2048

As reported by The Quantum Insider and South China Morning Post, the Chinese research team employed a 372-qubit quantum computer to crack RSA-2048 encryption, a cryptographic standard widely used to protect sensitive military information. RSA encryption relies on the difficulty of factoring large numbers, a task that classical computers would take thousands of years to solve. However, using quantum algorithms—specifically an enhanced version of Shor’s algorithm—the team demonstrated that quantum computers could break RSA-2048 in a much shorter time frame.

The breakthrough optimised Shor’s algorithm to function efficiently within the constraints of a 372-qubit machine. This marks a critical turning point in quantum computing, as it demonstrates the potential for quantum systems to tackle problems previously considered infeasible for classical systems. However, the paper from the Chinese Journal of Computers (2024) offers deeper insights into the quantum architecture and algorithmic refinements that made this breakthrough possible, highlighting both the computational power and limitations of the system.

Quantum Hardware and Algorithmic Optimisation

The technical aspects of the Chinese breakthrough, as detailed in the 2024 paper published in the Chinese Journal of Computers (CJC), emphasise the improvements in quantum hardware and algorithmic approaches that were key to this success. The paper outlines how the researchers enhanced Shor’s algorithm to mitigate the high error rates commonly associated with quantum computing, allowing for more stable computations over longer periods. This required optimising quantum gate operations, reducing quantum noise, and employing error-correction codes to preserve the integrity of qubit states.

Despite these improvements, the paper makes it clear that current quantum computers, including the 372-qubit machine used in this experiment, still suffer from several limitations. The system required an extremely controlled environment to maintain qubit coherence, and any deviation from ideal conditions would have introduced significant errors. Furthermore, the researchers faced challenges related to the scalability of the system, as error rates increase exponentially with the number of qubits involved. These limitations are consistent with the broader consensus in the field, as noted by Bill Buchanan and other experts, that practical quantum decryption on a global scale is not yet feasible.

The CJC paper also points out that while the breakthrough is impressive, it does not represent a complete realisation of quantum supremacy—the point at which quantum computers outperform classical computers across a wide range of tasks. The paper discusses the need for further advancements in quantum gate fidelity, qubit interconnectivity, and error correction to make quantum decryption scalable and applicable to broader, real-world encryption protocols.

Technical Analysis based on Li et al. (2024):

The paper explores two approaches for attacking RSA public key cryptography using quantum annealing:

1. Quantum Annealing for Combinatorial Optimization:

  • Method: This approach translates the mathematical attack method into a combinatorial optimization problem suited for the Ising model or QUBO model [1]. The Ising model represents a system of interacting spins, which can be mapped to the problem of factoring large integers used in RSA encryption.
  • Key Contribution: The paper proposes a high-level optimization model for multiplication tables and establishes a new dimensionality reduction formula. This formula reduces the number of qubits needed, thus saving resources and improving the stability of the Ising model [1]. The authors demonstrate this by successfully decomposing a two-million-level integer using a D-Wave Advantage system.
  • Comparison: This approach outperforms previous methods by universities and corporations like Purdue, Lockheed Martin, and Fujitsu [1]. This is achieved by significantly reducing the range of coefficients required in the Ising model, leading to a higher success rate in decomposition.
  • Focus: This technique represents a class of attack algorithms specifically designed for D-Wave quantum computers, known for their use of quantum annealing [1].

2. Quantum Annealing with Classical Methods:

  • Method: This approach combines the quantum annealing algorithm with established mathematical methods for cryptographic attacks, aiming to optimize attacks on specific cryptographic components [1]. It integrates the classical lattice reduction algorithm with the Schnorr algorithm.
  • Key Contribution: The authors leverage the quantum tunneling effect to adjust the rounding direction within the Babai algorithm, allowing for precise vector determination, a crucial step in the attack [1]. Quantum computing’s exponential acceleration capabilities address the challenge of calculating numerous rounded directions, essential for solving lattice problems [1]. Additionally, the paper proposes methods to improve search efficiency for close vectors, considering both qubit resources and time costs [1]. Notably, it demonstrates the first 50-bit integer decomposition on a D-Wave Advantage system, showcasing the algorithm’s versatility [1].
  • Comparison: The paper argues that D-Wave quantum annealing offers a more practical approach for smaller-scale attacks compared to Variational Quantum Algorithms (VQAs) on NISQ (Noisy Intermediate-Scale Quantum) computers. VQAs suffer from the “barren plateaus” problem, which can hinder algorithm convergence and limit effectiveness [1]. Quantum annealing is less susceptible to this limitation and offers an advantage when dealing with smaller-scale attacks.

Citations:

  1. Li, Gao, et al. “A Novel Quantum Annealing Attack on RSA Public Key Cryptosystems.” WC 2024 (2024).

Implications for Civilian Encryption: Limited Immediate Impact

While the Chinese breakthrough is undeniably significant, it is essential to recognise that the decryption of military-grade encryption does not immediately translate to vulnerabilities in civilian encryption protocols. Most personal and business communications rely on RSA-1024, elliptic-curve cryptography (ECC), or other lower-bit encryption systems. These systems remain secure against the capabilities of today’s quantum computers.

Moreover, as highlighted in the paper by Buchanan and echoed in the CJC analysis, many organisations are already transitioning towards post-quantum cryptography (PQC). PQC algorithms are specifically designed to withstand quantum attacks, ensuring that even as quantum computers advance, encryption systems will evolve to meet new threats.

Another key point raised by the CJC paper is that quantum decryption requires an immense amount of resources and computational power. The system used to break RSA-2048 involved highly specialised hardware and extensive computational time. Scaling such an operation to break everyday encryption protocols, such as those used in internet banking or personal communications, would require quantum computers with far more qubits and error-correction capabilities than are currently available.

Preparing for a Quantum Future: Post-Quantum Cryptography

As quantum computing technology evolves, it is imperative that governments, companies, and cybersecurity professionals continue preparing for the eventual reality of quantum decryption. This preparation includes developing and implementing post-quantum cryptographic solutions that are immune to quantum attacks. The National Institute of Standards and Technology (NIST) has already initiated efforts to standardise post-quantum cryptographic algorithms, which are designed to be secure against both classical and quantum attacks. The CJC paper underlines the importance of this transition and suggests that PQC will likely become the new standard in encryption over the next decade.

In addition to PQC, the CJC paper highlights the need for ongoing research into hybrid encryption systems, which combine classical cryptographic techniques with quantum-resistant methods. These hybrid systems could provide a transitional solution, allowing existing infrastructure to remain secure while fully quantum-resistant algorithms are developed and implemented.

Conclusion: A Scientific Milestone with Limited Immediate Consequences

The Chinese research team’s quantum decryption of military-grade encryption is a groundbreaking scientific achievement, signalling that quantum computing is rapidly advancing towards practical applications. However, as emphasised in the technical analyses from the Chinese Journal of Computers and other sources, this breakthrough is not yet a direct threat to civilian encryption systems. Current quantum computers remain limited by their error rates, scalability challenges, and the need for controlled environments, preventing widespread decryption capabilities.

As organisations and governments prepare for a post-quantum future, the adoption of post-quantum cryptography and hybrid systems will be crucial in ensuring that encryption protocols remain robust against both classical and quantum threats. While the breakthrough highlights the potential power of quantum computing, its impact on everyday encryption is still years, if not decades, away.

References and Further Reading

  1. Bill Buchanan, “A Major Advancement on Quantum Cracking,” Medium, 2024.
  2. The Quantum Insider, “Chinese Scientists Report Using Quantum Computer to Hack Military-Grade Encryption,” October 11, 2024.
  3. South China Morning Post, “Chinese Scientists Hack Military-Grade Encryption Using Quantum Computer,” October 2024.
  4. Interesting Engineering, “China’s Scientists Successfully Hack Military-Grade Encryption with Quantum Computer,” October 2024.
  5. Shor, P.W., “Algorithms for Quantum Computation: Discrete Logarithms and Factoring,” Proceedings of the 35th Annual Symposium on Foundations of Computer Science, 1994.
  6. National Institute of Standards and Technology (NIST), “Post-Quantum Cryptography: Current Status,” 2024.
  7. Chinese Journal of Computers, “Quantum Algorithmic Enhancements in Breaking RSA-2048 Encryption,” 2024.
Tech Founder to CTO: The Hidden Challenges of Managing Growth in Startups

Tech Founder to CTO: The Hidden Challenges of Managing Growth in Startups

The role of the Chief Technology Officer (CTO) in a startup is dynamic and challenging, particularly for first-time technical cofounders. While the early stages of a startup demand intense technical involvement and innovation, the role evolves significantly as the company grows. This evolution often highlights stark differences in the required skill sets at different stages, posing challenges for first-time technical cofounders but offering opportunities for serial entrepreneurs.

The Initial Phase: Technical Mastery and Hands-On Development

In a startup’s early days, the technical cofounder, often assuming the CTO role, is deeply immersed in product development’s intricacies. This period is characterized by rapid prototyping, extensive coding, and constant iteration based on user feedback. The technical cofounder’s primary focus is to bring the product vision to life, often working with limited resources and under significant time pressure. This phase requires not just technical expertise but also a high degree of creativity and problem-solving prowess.

The Transition: From Builder to Leader

As the startup scales, the CTO’s demands change dramatically. The focus shifts from hands-on development to strategic leadership. This transition involves managing larger teams, setting long-term technical directions, and ensuring that the technology strategy aligns with the overall business goals. First-time technical cofounders often find this shift challenging because it demands skills they may not have developed. The ability to code and build is no longer enough; the role now requires people management, strategic planning, and the capacity to handle complex organizational dynamics.

The Skill Set Gap

For first-time technical cofounders, this transition can be particularly daunting. Their expertise lies in building and innovating, but scaling a technology team and managing a growing organization are entirely different challenges. These new responsibilities require experience in leadership, communication, and strategic thinking—areas where first-time founders might lack experience. The result is a skill set gap that can lead to frustration and inefficiency, both for the individual and the organization.

Serial Entrepreneurs: Experience Matters

In contrast, serial entrepreneurs often handle this transition more effectively. Having navigated the startup journey multiple times, they possess a broader range of skills and experiences. They are familiar with the different phases of growth and the changing demands of the CTO role. Serial entrepreneurs are better equipped to balance hands-on technical work with strategic leadership. They have likely experienced the pitfalls and challenges of scaling a company before and have developed the necessary skills to manage them.

Learning from Experience

Serial entrepreneurs and or seasoned engineering leaders bring a wealth of knowledge from their previous ventures, allowing them to anticipate challenges and implement solutions proactively. Their past experiences help them build robust management structures, delegate effectively, and maintain strategic focus. This adaptability and foresight are crucial for a scaling startup, where the ability to pivot and adjust is often the difference between success and failure.

The Burnout Factor

Another critical difference is how first-time technical cofounders and serial entrepreneurs handle burnout. The relentless pace and high stakes of a startup can lead to significant stress and fatigue. First-time founders, driven by their passion and vision, might find it hard to step back and delegate, leading to burnout. On the other hand, serial entrepreneurs, having experienced this before, are often more adept at recognizing the signs of burnout and taking steps to mitigate it. They understand the importance of work-life balance and are better at creating a sustainable work environment for themselves and their teams.

Strategic Decisions and Stakeholder Management

As startups grow, they attract more investors and stakeholders whose interests need to be managed. Serial entrepreneurs typically have more experience dealing with investors and understanding their expectations. They are skilled at navigating the complex landscape of stakeholder management, making strategic decisions that align with the broader goals of the company while maintaining the confidence of their investors.

Conclusion: The Path Forward

For startups, recognizing the strengths and limitations of their technical cofounders is crucial. While first-time technical cofounders bring passion and technical prowess, they may struggle with the strategic and managerial aspects as the company scales. In contrast, serial entrepreneurs, with their diverse experiences and refined skills, are often better suited to handle the evolving demands of the CTO role.

Startups should consider these dynamics when planning their leadership strategies. Providing support, mentorship, and training to first-time technical cofounders can help bridge the skill set gap. Alternatively, involving experienced leaders who can complement the technical cofounder’s strengths can create a balanced leadership team capable of steering the company through its growth phases.

Ultimately, the journey from a technical cofounder to a successful CTO is complex and challenging. Recognizing the unique contributions and potential limitations of first-time technical cofounders, while leveraging the experience of serial entrepreneurs, can significantly enhance a startup’s chances of success.

What Happens When Huge Capital Meets No Real Product? Welcome to AI Speculation!

What Happens When Huge Capital Meets No Real Product? Welcome to AI Speculation!

Despite its hefty $1.3 billion investment, the recent collapse of Inflection serves as a stark reminder of the volatile AI startup landscape. Inflection’s flagship product, Pi, a ChatGPT rival, failed to gain traction, leading to the company’s dismantling by Microsoft. This case exemplifies the broader trend of massive capital influx into AI ventures lacking substantial products.

The Rise and Fall of Inflection

Inflection was founded by notable entrepreneurs such as Mustafa Suleyman of DeepMind, Karén Simonyan, and Reid Hoffman. Suleyman, a co-founder of DeepMind, had previously contributed to its advancements in AI, which eventually led to its acquisition by Google. Simonyan brought extensive experience from his work on AI research, while Hoffman, co-founder of LinkedIn, provided substantial entrepreneurial and investment acumen.

With backing from influential investors including Bill Gates and Eric Schmidt, Inflection aimed to create a more empathetic AI companion. The company took around two years to develop Pi, its primary product, hoping to leverage its founders’ reputations and the significant capital raised to break into the AI market.

Why Pi Failed

Pi’s failure is attributed to several factors:

  • Lack of Unique Value: Pi’s context window was significantly shorter than competitors, hindering its ability to provide sustained conversational quality.
  • Market Oversaturation: The AI companion market is fiercely competitive, with established players like ChatGPT and Character.ai leading the pack.
  • Financial Mismanagement: Heavy investment without a corresponding viable product highlighted the risks of capital-heavy ventures in AI.

AI Funding and Startup Failures

The AI sector saw an estimated $50 billion in investments in 2023 alone. However, many startups have failed to deliver on their promises. Some notable closures in the last 18 months include:

  • Inflection: Absorbed by Microsoft, ceasing independent operations.
  • Vicarious: Acquired by Alphabet, failing to achieve its goal of human-like AI.
  • Element AI: Acquired by ServiceNow after struggling to commercialize its research.
StartupTotal
Investment ($M)
Years to
Product Launch
Peak Annual
Revenue ($M)
Outcome
Inflection130025Acquired by Microsoft
Vicarious15042Acquired by Alphabet
Element AI257310Acquired by ServiceNow
MetaMind4521Acquired by Salesforce
Geometric Intelligence6010.5Acquired by Uber

The Future of AI Investment

This trend of high investment but low product viability raises concerns about the future of AI innovation. Consolidation around major players like Microsoft, Google, and OpenAI could stifle competition and limit diversity in AI development.

Conclusion

The downfall of Inflection underscores the precarious nature of AI investments. As the industry continues to grow, investors must prioritize viable, innovative products over mere potential. This shift could foster a more sustainable and dynamic AI ecosystem.

Inside the Palantir Mafia: Secrets to Succeeding in the Tech Industry

Inside the Palantir Mafia: Secrets to Succeeding in the Tech Industry

In the world of technology, engineers are not just cogs in a machine; they are the builders, the dreamers, and the ones who solve the problems they see in the world. And sometimes, those solutions turn into billion-dollar businesses. This is the story of the “Palantir Mafia,” a group of former Palantir employees who have left the data analytics giant to found their own startups, just like the famed “PayPal Mafia” that produced companies like SpaceX, YouTube, LinkedIn, Palantir Technologies, Affirm, Slide, Kiva, and Yelp.

1. Introducing the Amazing People from Palantir

The “Palantir Mafia,” akin to the renowned “PayPal Mafia,” comprises former Palantir engineers and executives who left to tackle meaningful problems with technological innovation, creating substantial impact and wealth. Unlike ex-consultants from firms like McKinsey, BCG, or Bain, these tech leaders leverage their deep technical expertise to solve complex issues directly, resulting in profound advancements and successful ventures.

Key Figures and Their Ventures

  1. Alex Karp – Palantir Technologies
    • Former Role: Co-Founder and CEO
    • Company: Palantir Technologies
    • Focus: Data analytics
    • Market Penetration: Widely used across government and commercial sectors
    • Revenue: $1.5 billion annually
    • Capital Raised: $3 billion​ (Wikipedia)​​ (Business Insider)​
  2. Max Levchin – Affirm
    • Former Role: Co-Founder (PayPal, associated with Palantir founders)
    • Company: Affirm
    • Focus: Buy now, pay later financial services
    • Market Penetration: Significant presence in the consumer finance market
    • Revenue: $870 million in fiscal 2021
    • Capital Raised: $1.5 billion
  3. Joe Lonsdale – 8VC
    • Former Role: Co-Founder
    • Company: 8VC
    • Focus: Venture capital firm
    • Market Penetration: Diverse portfolio, influential in tech sectors
    • Assets Under Management: $3.6 billion
  4. Palmer Luckey – Anduril Industries ( could be the blue blooded Musk of 2020-2030s)
    • Former Role: Founder of Oculus VR, associated with Palantir through ventures
    • Company: Anduril Industries
    • Focus: Defense technology
    • Innovation: Developed the Lattice AI platform for autonomous border surveillance and defense applications
    • Market Penetration: Contracts with U.S. Department of Defense and border security agencies
    • Revenue: $200 million annually
    • Capital Raised: $700 million
  5. Garrett Smallwood – Wag!
    • Former Role: Executive roles at other startups before Wag!
    • Company: Wag!
    • Focus: On-demand pet care services
    • Market Penetration: Operates in over 100 cities
    • Revenue: $100 million annually
    • Capital Raised: $361.5 million
  6. Nima Ghamsari – Blend
    • Former Role: Product Manager at Palantir
    • Company: Blend
    • Focus: Mortgage and lending software
    • Market Penetration: Partners with major financial institutions
    • Revenue: Estimated $100 million+ annually
    • Capital Raised: $665 million
  7. Stephen Cohen – Quantifind
    • Former Role: Co-Founder of Palantir
    • Company: Quantifind
    • Focus: Risk and fraud detection using data science
    • Market Penetration: Used by financial services and government sectors
    • Capital Raised: $8.7 million
  8. Vibhu Norby – B8ta
    • Former Role: Engineer at Palantir
    • Company: B8ta
    • Focus: Retail-as-a-service platform
    • Market Penetration: Transforming in-store retail experiences
    • Capital Raised: $113 million
  9. Joe Lonsdale – Addepar
    • Former Role: Co-Founder of Palantir
    • Company: Addepar
    • Focus: Wealth management technology
    • Market Penetration: Manages over $2 trillion in assets
    • Capital Raised: $325 million
  10. Raman Narayanan – SigOpt
    • Former Role: Data Scientist at Palantir
    • Company: SigOpt (acquired by Intel)
    • Focus: Machine learning optimization
    • Market Penetration: Utilized by top tech companies
    • Capital Raised: $8.7 million (before acquisition)

2. Engineers Make Better Founders in the Tech Industry

Unlike ex-consultants from big 3 who may excel in strategy and communication but often lack the technical depth to truly understand the intricacies of building a tech product, these ex-Palantir engineers come armed with both the vision and the technical chops to bring their ideas to life. They’ve spent years wrestling with complex data problems at Palantir, and they’re now taking those hard-won lessons to solve new challenges across a wide range of industries.

Engineers bring a problem-solving mindset that focuses on creating practical, scalable solutions. This technical acumen has allowed former Palantir employees to launch transformative companies that push the boundaries of what’s possible in various industries.

3. Market Penetration and Success of Palantir Alumni

The success of these Palantir alumni is evident through their market penetration and revenue. For instance, Palantir Technologies itself is a major player in the data analytics field, with a revenue of $1.5 billion annually. Affirm, led by Max Levchin, has made significant inroads in the consumer finance market, generating $870 million in revenue in fiscal 2021. Anduril Industries, founded by Palmer Luckey, has secured substantial contracts with the U.S. Department of Defense, contributing to its $200 million annual revenue.

Other successful ventures include Blend, with its deep partnerships with major financial institutions, and Addepar, managing over $2 trillion in assets. These companies not only showcase the technical expertise of their founders but also highlight their ability to penetrate markets and achieve substantial financial success.

4. Engineers vs. Consultants: A Compelling Argument

The technical depth and problem-solving mindset of engineers make them particularly suited for founding and leading tech startups. Their ability to directly tackle complex problems contrasts with the approach of ex-consultants from firms like McKinsey, BCG, or Bain, who often focus more on financial and operational efficiencies.

While consultants excel in operations-heavy startups, where strategic planning, financial management, and operational efficiency are paramount, engineers thrive in tech startups that require innovative solutions and deep technical expertise. The success stories of the Palantir alumni underscore this distinction, demonstrating how their engineering backgrounds have enabled them to drive significant technological advancements and build successful companies.

Conclusion

The Palantir Mafia’s engineers have leveraged their technical expertise to create innovative solutions and successful ventures, driving significant impact across various industries. Their ability to tackle complex problems directly contrasts with the approach of ex-consultants from firms like McKinsey, BCG, or Bain, who often focus more on financial and operational efficiencies. This technical depth has enabled these former Palantir employees to become influential leaders, pushing the boundaries of technology and innovation.

References & Further Reading:

  1. https://www.getpin.xyz/post/the-palantir-mafia
  2. https://www.8vc.com/resources/silicon-valleys-newest-mafia-the-palantir-pack
  3. https://www.youtube.com/watch?v=a_nO6RW7ddQ
  4. https://www.businessinsider.in/the-life-and-career-of-alex-karp-the-billionaire-ceo-whos-taking-palantir-public-in-what-could-be-one-of-the-biggest-tech-ipos-of-the-year/articleshow/78198300.cms
  5. https://en.wikipedia.org/wiki/Alex_Karp
Non-Compete Clauses: FTC’s Influence on Tech Innovation & Employee Freedom

Non-Compete Clauses: FTC’s Influence on Tech Innovation & Employee Freedom

The recent FTC ruling banning most non-compete agreements nationwide has ignited a firestorm in the business world. While some cheer the increased freedom for workers, others fear a potential talent exodus and a decline in innovation. Let’s delve deeper into this debate, exploring the arguments for and against non-compete clauses, along with the potential consequences of the ruling.

Champions of the Free Agent: A Rising Tide Lifts All Boats

Proponents of the FTC’s decision paint a rosy picture. They argue that:

  • Increased Worker Mobility: With non-compete shackles removed, workers can freely pursue more lucrative opportunities. This competition between companies drives salaries upwards, forcing employers to offer competitive benefits packages to retain talent.
  • Innovation on Steroids: A more mobile workforce fosters a cross-pollination of ideas. Employees bring fresh perspectives and experiences from previous roles, leading to a more dynamic and innovative environment across industries.
  • Empowering the Underdog: Critics of non-competes argue that these clauses disproportionately affect low-wage workers. They often lack the resources to challenge them in court, effectively becoming trapped in jobs with limited upward mobility.

The Employer’s Lament: Protecting the Crown Jewels

Companies are understandably nervous about the FTC’s ruling. Here’s why:

  • Trade Secrets at Risk: Businesses worry that departing employees, especially those privy to sensitive information, might jump ship to a competitor, potentially taking valuable trade secrets with them. This could give a rival an unfair advantage and stifle innovation.
  • Customer Loyalty on the Move: Companies also fear losing established customer relationships when key salespeople or account managers move on to a competitor. This could lead to a decline in customer retention and revenue.
  • Poaching Wars: A Race to the Bottom: Without non-compete clauses, some companies worry about fierce “poaching wars” erupting, where competitors aggressively recruit talent and drive up salaries for specific roles. While this might benefit a select few employees, it could negatively impact smaller companies with limited resources.

The Nuance: Not All Non-Compete Clauses Are Created Equal

It’s important to acknowledge that the FTC ruling has some limitations. Here are some potential grey areas:

  • Executive Contracts: The ruling may not apply to high-level executives whose contracts often contain stricter non-disclosure and non-compete clauses. These agreements might still be enforceable depending on specific terms.
  • State Variations: While the FTC ruling aims to be a blanket policy, some states might have stricter or more lenient regulations regarding non-compete clauses. Employers and employees should be aware of their state’s specific laws.
  • Industry Specificity: The FTC ruling might have a more significant impact on specific industries like tech, where knowledge transfer and trade secrets are particularly valuable. Other sectors may be less affected.

The Future of Work: A Brave New World?

The FTC’s ruling is a major turning point that could significantly reshape the American workforce. It’s too early to predict the full impact, but some potential scenarios include:

  • Rise of the Free Agent Economy: Highly skilled workers with in-demand expertise may become more like free agents, negotiating short-term contracts or project-based work with various companies.
  • Focus on Retention Strategies: Companies may shift their focus towards creating a more positive work environment that fosters loyalty and discourages employees from leaving. This could include better benefits, training opportunities, and a strong company culture.
  • Increased Use of Confidentiality Agreements: Non-compete clauses may be replaced by stricter confidentiality agreements to protect sensitive information, although their enforceability might vary.
The Fork in the Road: The Curveball that Redis Pitched

The Fork in the Road: The Curveball that Redis Pitched

In a move announced on March 20th, 2024, Redis, the ubiquitous in-memory data store, sent shockwaves through the tech world with a significant shift in its licensing model. Previously boasting a permissive BSD license, Redis transitioned to a dual-license approach, combining the Redis Source Available License (RSAL) and the Server Side Public License (SSPL). This move, while strategic for Redis Labs, has created ripples of concern in the SAAS ecosystem and the open-source community at large.

The Split: From Open to Source-Available

At its core, the change restricts how users, particularly cloud providers offering managed Redis services, can leverage the software commercially. The SSPL, outlined in the March 24th press release, stipulates that any derivative work offering the “same functionality as Redis” as a service must also be open-sourced. This directly impacts companies like Amazon (ElastiCache) and DigitalOcean, forcing them to potentially alter their service models or acquire commercial licenses from Redis Labs.

A History of Licensing Shifts

This isn’t the first time Redis Labs has ruffled feathers with licensing changes. As a 2019 TechCrunch article [1] highlights, Redis Labs has a history of tweaking its open-source license, sparking similar controversies. Back then, the company argued that cloud providers were profiting from Redis without giving back to the open-source community. The new SSPL appears to be an extension of this philosophy, aiming to compel greater contribution from commercial users.

SAAS Providers in a Squeeze

For SAAS providers, the new licensing throws a wrench into established business models. Modifying core functionality to comply with the SSPL might not be feasible, and open-sourcing their entire platform could expose proprietary code. This could lead to increased costs for SAAS companies, potentially impacting end-user pricing.

Open Source Community Divided

The open-source world is also grappling with the implications. While the core Redis functionality remains open-source under RSAL, the philosophical shift towards a more restrictive model has some worried. The Linux Foundation even announced a fork, Valkey, as an alternative, backed by tech giants like Google and Oracle. This fragmentation could create confusion and slow down innovation within the open-source Redis ecosystem.

The Road Ahead: Uncertainty and Innovation

The long-term effects of Redis’s licensing change remain to be seen. It might pave the way for a new model for open-source software sustainability, where companies can balance community development with commercial viability. However, it also raises concerns about control and potential fragmentation within open-source projects.

In conclusion, Redis’s licensing shift presents a complex scenario. While it aims to secure Redis Labs’ financial future, it disrupts the SAAS landscape and creates uncertainty in the open-source world. Only time will tell if this is a necessary evolution or a roadblock to future innovation.

References & Further Reading:

Why Startups Need To Architect Cloud Agnostic Products

Why Startups Need To Architect Cloud Agnostic Products

Nobody plans to leave AWS in the startup world, but as they say, “sh** happens.”

An image of multiple clouds over a desk

As engineers, when we write software, we’re taught to keep it elegant by never depending directly on external systems. We write wrappers for external resources, we encapsulate data and behaviour and standardise functions with libraries. 

But, When it comes to the cloud… “eerie silence”

Companies have died because they needed to move off AWS or GCP but couldn’t do it in a reasonable and cost-effective timeline.

We (at Itilite) had a close call with GCP, which served as our brush with the fire. Google had arguably one of the best Distance Matrix capabilities out there.  It was used in one of our core logic and ML models. And on one fine Monday afternoon, I have to set up a meeting with my CEO to communicate that we will have to spend ~250% more on our cloud service bill in about 60 days.

Actually, google increased the pricing by 1400% and gave 60 days to rewrite, migrate, move out or perish!  

The closest competitor in terms of capability was DistanceMatrix and a reliable “Large” player was Bing. But, both left a lot for in the “Accuracy”. So, for us, the business decision was simple: make the entire product work in “Reduced Functionality” mode for all or start differential pricing for better accuracy!  In either case, those APIs must be rewritten with a new adaptor. 

It is not an enigma why we do this. It’s simple: there are no alternatives, there is no time to GTM,  But maybe there is. I’ll explain why you should take cloud-agnostic architecture seriously and then show you what I do to keep my projects cloud-agnostic.

Cloud Service Rationalisation

The prime reason you should consider the ability to switch clouds and cloud services is so you can choose to use the cloud service that is price and performance-optimized for your use case.

When I first got into serverless, we wrote a transformative API on Oracle Cloud (Bcoz we were part of their Accelerator Program and had a huge credit.) but it fed part of the data that the customer-facing API relied on.

No prize for guessing what happened?

It was a horrible mistake. Our API had an insane latency problem. Cold start requests added additional latency of at least 2 seconds per request. The AWS team has worked hard to build a service that can do things that GCP’s Cloud Functions simply can’t, specifically around cold starts and latency.

I had to move my infrastructure to a different service and a revised network topology.

Guess we would have learned the problem by now, but as we will find out, we did not.

This time it was a combination of Kafka and the AWS Lambda that created an issue. We had relied on Confluent’s connectors for much of the workload interfaces and had to shell out almost $1000 per month per connector!

Avoiding the Cloud Provider Killswitch

Protect Your Business from Unexpected Termination

As a CXO, you may not be aware that cloud providers like AWS, GCP, and Azure reserve the right to terminate your account and destroy your infrastructure at any time, effectively shutting down your business operations. While this may seem like an extreme measure, it’s important to understand that cloud providers have strict terms of service that can lead to account termination for a variety of reasons, even if you’re not engaged in illegal or harmful activities.

A Chilling Example

I recently spoke with a friend who is the founder of a fintech platform. He shared a chilling incident that highlights the risks of relying on cloud providers. His team was using GCP’s Cloud Run, a container service, to host their API. They had a unique use case that required them to call back to their own API to trigger additional work and keep the service active. Unfortunately, GCP monitors this type of behaviour and flags it as potential crypto-mining activity.

On an ordinary Sunday, their infrastructure vanished, and their account was locked. It took them six days of nonstop effort to migrate to AWS.

Protect Your Business

This incident serves as a stark reminder that any business operating on cloud infrastructure is vulnerable to unexpected termination. While you may not be intentionally engaging in activities that violate cloud provider terms of service, it’s crucial to build your infrastructure with the possibility of termination in mind.

Here are some key steps you can take to protect your business from the cloud provider killswitch:

  1. Read and understand the terms of service for each cloud provider you use.
  2. Choose a cloud provider that aligns with your industry and business model.
  3. Avoid relying on a single cloud provider.
  4. Have a backup plan in place.
  5. Regularly review your cloud usage and ensure compliance with cloud provider terms of service.

By taking these proactive measures, you can significantly reduce the risk of your business being disrupted by cloud provider termination and ensure the continuity of your operations.

Unleash the Power of Free Cloud Credits

For early-stage startups operating on a shoestring budget, free cloud credits can be a lifeline, shielding your runway from the scorching heat of cloud infrastructure costs. Acquiring these credits is a breeze, but the way most startups build their infrastructure – akin to an unbreakable blood oath with their cloud provider – restricts them to the credits granted by that single provider.

Why limit yourself to the generosity of one cloud provider when you could seamlessly switch between them to optimize your resource allocation? Imagine the possibilities:

  • AWS to GCP: Upon depleting your AWS credits, you could effortlessly migrate your infrastructure to GCP, taking advantage of their generous $200,000 credit offer.
  • Y Combinator: As a Y Combinator startup, you’re entitled to a staggering $150,000 in AWS credits and a mind-boggling $200,000 on GCP.
  • AI-Powered Startups: If you’re developing AI solutions, Azure welcomes you with open arms, offering $300,000 in free credits to fuel your AI models on their cloud.

By embracing cloud-agnostic architecture, you unlock the freedom to switch between cloud providers, potentially saving you a significant $200,000 upfront. Why constrain yourself to a single cloud provider when cloud-agnosticism empowers you to navigate the cloud landscape with flexibility and cost-efficiency?

Building Resilience: The Importance of Cloud Redundancy

In the ever-evolving world of technology, no system is immune to failure. Even industry giants like Silicon Valley Bank can outright disappear over a weekend or AWS’ main Datacenter can go offline due to a power fluctuation, highlighting the importance of proactively safeguarding your business operations.

Imagine the potential financial impact of a 12-hour outage on AWS for your company. The costs could be staggering, not only in lost revenue but also in reputational damage and customer dissatisfaction or even potential churn.

This is where cloud redundancy comes into play. By running parallel segments of your platform on multiple cloud providers, such as AWS and GCP, you’re essentially creating a fail-safe mechanism.

In the event of an outage on one cloud platform, the other can seamlessly pick up the slack, ensuring uninterrupted service for your customers and minimizing the impact on your business. Cloud redundancy is not just about disaster preparedness; it’s also about optimizing performance and scalability. By distributing your workload across multiple cloud providers, you can tap into the unique strengths and resources of each platform, maximizing efficiency and responsiveness.

In our case, we run the OCR packages, SAML, and Accounts service on Azure, our core “Recommendation engine” and “Booking Engine” on AWS. Yes, having a multi-cloud will involve initial costs that might be prohibitive, but in the long run, the benefits will far outweigh the costs.

Cloud Cost Negotiation: A Matter of Leverage

In the realm of business negotiations, the ultimate power lies in the ability to walk away. If the other party senses your lack of alternatives, they gain a significant advantage, effectively holding you hostage. Cloud cost negotiations are no exception.

Imagine you’ve built a substantial $10 million infrastructure on AWS, heavily reliant on their proprietary APIs like S3, Cognito, and SQS. In such a scenario, walking away from AWS becomes an unrealistic option. You’re essentially at their mercy, accepting whatever cloud costs they dictate.

While negotiating cloud costs may seem insignificant to a small company, for an organization with $10 million of AWS infrastructure, even a 3% discount translates into substantial savings.

To gain leverage in cloud cost negotiations, you need to establish a credible threat of walking away. This requires careful planning and strategic implementation of cloud-agnostic architecture, enabling you to seamlessly switch between cloud providers without disrupting your operations.

Cloud Agnosticism: Your Negotiating Edge

Cloud-agnostic architecture empowers you to:

  1. Diversify your infrastructure: Run your applications on multiple cloud platforms, reducing reliance on a single provider.
  2. Reduce switching costs: Design your infrastructure to minimize the effort and cost of migrating to a new cloud provider.
  3. Strengthen your negotiating position: Demonstrate to cloud providers that you have alternative options, giving you more bargaining power.

By embracing cloud-agnosticism, you transform from a captive customer to a savvy negotiator, capable of securing favorable cloud cost terms.

Unforeseen Challenges: The Importance of Cloud Agnosticism

In the dynamic world of business, unforeseen challenges (and opportunities) can arise at any moment. We often operate with limited visibility, unable to predict every possible scenario that could impact our success. Here’s an actual scenario that highlights the importance of cloud-agnostic architecture:

Acquisition Deal Goes Through

This happened with One of my previous organisations, we tirelessly built this company from the ground up. Our hard work and dedication paid off when a large SaaS Unicorn approached us with an acquisition proposal.

However, during the due diligence, a critical issue emerged: Our company’s infrastructure was entirely reliant on AWS. The Acquiring company had a multi-year multi-million dollar deal with Azure and the M&A team made it clear that unless our platform can operate on Azure, the deal is off the table!

Our team faced the daunting task of migrating the entire infrastructure to Azure within a limited timeframe and budget. Unfortunately, the complexities of the migration proved time-consuming and the merger took 5 months to complete and the offer was reduced by $2 million!

The Power of Cloud Agnosticism

This story serves as a stark reminder of the risks associated with a single-cloud strategy. Had our company embraced cloud-agnostic architecture, we would have possessed the flexibility to seamlessly switch between cloud providers, potentially leading to a bigger exit for all of us!

Cloud-agnostic architecture offers several benefits:

  • Reduced Vendor Lock-in: Avoids dependence on a single cloud provider, empowering you to switch to more favourable options based on your needs.
  • Improved Negotiation Power: Gains leverage in cloud cost negotiations by demonstrating the ability to switch providers.
  • Increased Resilience: Protects your business from disruptions caused by cloud provider outages or policy changes.
  • Enhanced Scalability: Enables seamless expansion of your infrastructure across multiple cloud platforms as your business grows.

Embrace Cloud Agnosticism for Business Continuity

In today’s ever-changing technological landscape, cloud-agnostic architecture is not just a benefit; it’s a necessity for businesses seeking long-term success and resilience. By adopting a cloud-agnostic approach, you empower your company to navigate the complexities of the cloud landscape with agility, adaptability, and cost-efficiency, ensuring that unforeseen challenges don’t derail your journey.

My Solution

Here’s what I do about it, now after the lessons learnt. I use Multy. Multy is an open-source tool that simplifies cloud infrastructure management by providing a cloud-agnostic API. This means that developers can define their infrastructure configurations once and deploy them to any cloud provider without having to worry about the specific syntax or nuances of each cloud platform. While Multy provides an abstraction layer for deploying cross-cloud environments, you will also need to incorporate cloud-environment agnostic libraries to really make a difference.

References & Further Reading: 

  1. https://kobedigital.com/google-maps-api-changes/
  2. https://www.reddit.com/r/geoguessr/comments/cslpja/causes_of_google_api_price_increase_suggestion/ 
  3. https://multy.dev/
  4. https://github.com/multycloud/multy
  5. https://github.com/serverless/multicloud 
  6. https://aws.amazon.com/startups/credits
How to Manage Technical Debt in 2023: A Guide for Leadership

How to Manage Technical Debt in 2023: A Guide for Leadership

In this article, I will summarise effective strategies and best practices to tackle tech debt head-on.

Technical debt is an inevitable reality in software development. But, it can be leveraged just like a financial loan/debt can help you achieve your goals, if managed properly.
It can be used to drive competitive advantage by allowing companies to launch new products and features faster, experiment with new technologies, and improve the scalability and performance of their systems. However, like all loans, it need to be “Repaid” properly and at the right time, failing on it will create a downward spiral.

If you’re not careful, technical debt can quickly become a major burden that slows down development and makes it difficult to add new features or even fix bugs in a timely manner.

We will discuss how to identify technical debt and the signs of poorly managed debt, and then provide a strategy for reducing it. We will also discuss what a healthy level of technical debt looks like and how leaders can use it to their advantage.

Good Tech Debt Vs Bad Tech Debt

Robert Kiyosaki, the author of Rich Dad Poor Dad, famously said:

Bad debt takes money out of your pocket, while good debt puts money in your pocket.

– Robert Kiyosaki

The same is true of tech debt.

Technical debt is the cost of not doing things the right way the first time. Good technical debt is accrued when you make trade-offs to meet deadlines or deliver new features quickly. Bad technical debt is accrued when you make poor decisions or cut corners.

Bad tech debt will probably make your PMs, Sales and CEO happy for a quarter or two. But after that, they will be asking why everything is behind schedule and dealing with customer complaints because things aren’t working properly.

Now that I have presented the obvious in a familiar “Quadrant”, you can actually skip the terminologies and definitions part of this article! 😀

For my verbal brethren, Which is the Tech Debt you’d need to ruthlessly hunt down to extinction? Obviously, it is the untracked, undocumented ones. And the ones which are dragging your team on a downward spiral (immaterial of whether it is tracked or not)

Why does your Tech Debt keep accumulating?

Before we can think about building a strategy to solve tech debt, we need to understand how it gets out of control in the first place.

It’s called “impact visibility”.

Fixing code debt issues is impossible if:

1, You’ve no record of what technical debt issues you have

2, You’ve got a backlog, but you can’t see which issues are related to what code

In both cases, you can’t prioritise tech debt over shipping new features.

We need to get more granular about what impacts these two tech debt cases above.

  • Issue invisibility — There’s no source of shared knowledge. Codebase health info is locked in (few) engineers’ heads.
  • No code quality culture — Shipping fast, whatever the cost, like it’s going out of fashion.
  • Poor process — Tech debt work sucks. Nobody likes creating Jira tickets. “Jira” has become a dirty word.
  • Low-time investment — Justifying the time to fix tech debt or to refactor is a constant uphill battle. After a point, engineers become silent!

Lack of context — Issues in Jira are a world away from the hard reality of the codebase. They’re not related in any way.

So what’s the source of this? Let’s talk strategy.

Spoiler… It’s about changing organisational culture and developer behaviour to track issues properly.

Creating a strategy to reduce technical debt

Track. Issues. Properly.

Good tech debt management starts with team-wide excellence at tracking issues.

You can’t have a tech debt strategy without tracking.

The engineering leader’s job is to make that “issue tracking” easy for your team. There is supposed to be a software for that – Jira, Asana, Rally or something of that sort.

The problem is, I’ve never believed they really get to the bottom of the problem, and after speaking with scores of engineers and leaders about it, they usually don’t either. My personal belief is most companies suffer on the velocity after their Jira rollout! It is a bit like,

No two countries that both have a McDonald’s have ever fought a war against each other.

Thomas L. Friedman – in The Lexus and the Olive Tree!

As a leader, You need to find a way to…

  • Show engineers when they’re working on code with tech debt, without them having to jump thru 3 hoops.
  • Make it really easy for team members to report tech debt.
  • Create a natural way to discuss codebase issues.
  • Integrate tech debt work into your workflows and involve PMs if required.

There are multiple ways to achieve this, the easiest is to not address it. Ie: not address it intentionally, just tweak your existing pipeline. This can be done by,

  • A very robust linting & integration to the IDE
  • Tighter Git rules for commits
  • SAST which runs on the pipeline
  • and can feed into the IDE

Prioritising impactful tech debt

At this point, it should be obvious, but prioritising the right issues is only possible if you’re tracking the impact of these “issues” and it could be direct or indirect (Dependency, Sequencing, Rework avoidance etc) .

Once you’ve got them, you should regularly and consistently use them to decide what to address. This usually happens during the backlog grooming or sprint planning sessions. But, this decision-making process needs to be strategic. Not at all tactical, ie: DO NOT delegate it to the whims and whimsicals of your TL/PM or even EM.

You or someone with a context of the organisation and position on sales, clients, revenue etc., should be doing this.

A good way to start is by choosing a theme each time you prioritise issues. For example, you could prioritise issues that…

  • Are impacting a specific feature you need to work on in the next quarter
  • Are impacting the customer’s UX
  • Are affecting efficiency/morale on the team
  • Are impacting the security posture

This is often straightforward if you’ve got high-quality issues that traceable to code and tagged as such.

Most people wonder how to get the time for these “Tasks”. I have two recommendations.

  • Take an entire sprint every quarter to repay the tech debt (Will need high-level buy-in, It is slightly harder to align your CXOs)
  • Allocate 15-20% of bandwidth in every sprint. (Easier to achieve buy-in from CXOs, harder to drive with engineers)

Engineers generally won’t prioritise tech debt work by themselves because of the conflict of interest/pressure of shipping fast. This was evident from multiple high velocity/impact software engineering teams including ones at AirBnb, Netflix and Spotify. A commitment to code refactoring and maintenance work should be endorsed and supported from the top and reinforced regularly.

How much Tech Debt can you take on?

Managing technical debt is like managing financial debt. You can use it to your advantage, but you need to be careful not to let it get out of control.

Your technical debt budget is the amount of technical debt that you are willing to take on in order to achieve your business goals. You should not try to solve all of your technical debt at once, but instead focus on the most important items.

Prudent technical debt is debt that you take on deliberately and knowingly, in order to achieve a specific goal. For example, you might take on technical debt to launch a new product quickly, or to add a new feature that is in high demand by your customers.

If you manage your technical debt properly, it can be a powerful tool for gaining a competitive advantage. However, if you let your technical debt get out of control, it can lead to serious problems, such as increased costs, delays, and security vulnerabilities.

Concluding remarks:

Technical debt is one of the most neglected areas of software development. It is often only given priority when it is too late and has already caused serious problems.

However, when leaders work together and develop a consistent and process-driven strategy, technical debt can be effectively managed.

The best engineering teams are constantly thinking about how to use their technical debt budget to their advantage.

References and Further Reading:

No McKinsey, You got it all wrong about developer productivity!

No McKinsey, You got it all wrong about developer productivity!

Disclaimer: I have been an enormous proponent of Developer Productivity and have tried to implement automated metrics collection in 3 orgs with varied success. In my Mentoring sessions with early-stage startup leaders as well, I (re)enforce the importance of being aware of Dev Productivity. So much so, that I have written a 2-part article on the same here, here and here. I have also been a huge fan of McKinsey and how they seem to get answers which eluded the attention and resources of mega-corporations or governments alike. However, this article is written to communicate an entirely different perspective. In my opinion, McKinsey has got this entire “framework” thing about “dev productivity” wrong.

Introduction:

About a month back, McKinsey published an article claiming that they have developed a framework to measure productivity. They also acknowledged the fact that they were simply rehashing some of the existing metrics (like DORA and SPACE), which were used by Engineering Leaders and have simplified it (without the context) and are pitching it to their traditional buyers, the C-Suite executives in Mega corporations. Actually, some of these metrics can be useful tools if used correctly -One example is Hand-offs. But, the main reason I have chosen to write this article is their central focus seems to be “Coders should code”. It also appears to have A) missed the context of every metric, OR B) Omitted the context so as not to burden their target audience.

Finally, there is a mix-max of things to track, metrics to monitor and Opportunities to Focus, which looks like

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was reckless!

Captain Ramius Pointing to a young Jack Ryan that Admiral Halsey was Stupid!

The Legendary Kent Beck has written a deep 2-part piece on countering the conjectures presented by McKinsey and elaborating on the gaps that engineering orgs are traditionally bound to manifest. It is very well written and covers almost everything. There are also a bunch of other eminent Software Engineers who have written on this and I have tried to give a quick lot at the bottom of this article.

What Was I concerned about?

Focus On Activities

I was primarily concerned about the lack of focus on Outcomes and Impact and a focus on the “Activities” in the proposed framework!

Any engineering leader or manager will tell you that Code Review Velocity and Deployment Frequency have nothing to do with measuring outcomes. While I will not discount Cycle Time or MTTR (I take pride in building multiple teams with one of the lowest MTTR and Cycle times in the ecosystem). They are indicators of some process elements/activities that could lead to outcomes. If we want to measure something, it should be Outcomes, not activities!

Focus on Optimisation of Irrelevant Metrics

Code Review Velocity:

If you want to time-motion the code review process in the entire stream map, you’ll find that async code review is killing your productivity. Pairing improves that dramatically. Instead of trying to sub-optimize for code review, measure the thing we actually want to improve. Which will be “Cycel Time”.

Story Points Completed:

Let’s agree on a basic fact. A “story point” is a made-up number. It was conceived as yet another way to obfuscate estimates for thought work that is difficult to estimate. As originally conceived, it represented the number of mythical “ideal days” of effort. There’s so much time wasted on getting better at “story pointing,” arguing about the Fibonacci sequence, “planning poker,” and other story point nonsense. Frankly, it is one of the “Bad” elements of Scrum! As a leader, you should find and remove handoffs and wait times. Story points are useless for anything and even more useless for this goal. Track throughput instead. 

Handoffs:

This is a good one. Good job, McKinsey. You got something right. Stop using testing teams, use pairing instead of code review, operate what you build, and don’t have any people doing anything manual to the right of development.

Contribution Analysis and Opportunities focus

In the other focus areas, they have listed metrics at the individual level that can be useful unless you measure “developer satisfaction,” “retention,” and “interruptions” at the individual level. These should only be measured in aggregates to prevent any cognitive bias. IMO, Things start getting really toxic in the “Opportunities focus” section, though.

I have been part of organisations and processes where there was a focus on tracking and measuring the outcomes of individuals. It did not play out well, ever. My Conclusion after reading the article for the second time is that McKinsey thinks their intended audience (CEOs and CFOs) cannot understand “systems thinking.” Now, If you roll out this or a similar framework and announce this and what do you think will happen?

You have a group of people all working on the same backlog but not acting as a team. Code review suffers, mentoring sufferers, pairing is hard, work breakdown suffers, etc. Anything that requires more than one person to conduct/conclude, including helping someone get unstuck, will get deprioritised!

Overall, The inferences seem to be based on hard facts, but the conjectures are all flawed.

Why This Now?

At this point, I want to highlight what “Triggered” me to write this, read the following.,

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

McKinsey’s Article on the purported Framework

Wow. I pray for that company.

So, I believe after McKinsey pointed to the fact, that developers are involved in irrelevant things like design, architecture etc. They created separate towers of responsibility for design. In that case, I am puzzled about who will be responsible for the minor things like dependency management, prerequisites, versioning, capacity planning, concurrency, scalability etc.

Did they get anything Right?

Yes. There are tonnes, but they are buried at the bottom. Their focus on Hand-offs and cycle times are really worth tracking in any engineering org. To the authors’ credit, they have also identified some of the core issues with measuring Developer Productivity. But, someone higher in the firm seem to have suggested to soften the blow. So, they have diluted and buried those sections. I will share 2 gems here.

To truly benefit from measuring productivity, leaders and developers alike need to move past the outdated notion that leaders “cannot” understand the intricacies of software engineering, or that engineering is too complex to measure.

The real problem is that in many large organisations, “The Management” doesn’t understand the work they manage. Management can understand the intricacies of software engineering if they become leaders and study the work they manage. In a large behemoth, not all managers are leaders. They want a framework and will enforce it with an iron fist. Now, McKinsey has delivered them a framework!

Learn the basics. All C-suite leaders who are not engineers or who have been in management for a long time will need a primer on the software development process and how it is evolving.

This one Nailed it! The primary reason “Management” finds it difficult to measure the right thing is because they sometimes do not understand the work they want to measure. Leaders who understand do measure the right things. My primary concern with this framework is, in trying to solve this, McKinsey has made the problem worse!

Just google “McKinsey developer productivity” and you’ll find more articles on how this framework is flawed than the original article link!

Anto’s Response to the Article and the purported Framework.

References & Further Reading/Watching:

1, Mc.Kinsey Article – https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
2, Kent Beck’s rebuttal – https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
3, Redidit – https://www.reddit.com/r/programming/comments/1650595/measuring_developer_productivity_a_response_to/
4, Level Up Coding – https://levelup.gitconnected.com/the-developers-productivity-can-t-be-measured-in-mckinsey-s-way-an-analysis-4d81924279ae
5, Measuring Developers Productivity… McKinsey what’s the point? – https://www.youtube.com/watch?v=wjQn8nnkXTs
6, Can We Measure Developer Productivity? A Reaction to McKinsey’s Article – https://www.youtube.com/watch?v=ETa24ErdcwQ
7, HOW TO MEASURE ENGINEERING PRODUCTIVITY? – https://nocturnalknight.co/2022/11/how-to-measure-engineering-productivity/
8, Business Value delivery by Engineering Teams in StartUps – Part 1 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-1/#comment-773
9, Business Value Delivery by Engineering Teams in StartUps – Part 2 – https://nocturnalknight.co/2021/10/business-value-delivery-by-engineering-teams-in-startups-part-2/
10, Space Metrics – https://www.harness.io/blog/space-metrics-get-started
11, DORA Metrics – https://www.leanix.net/en/wiki/vsm/dora-metrics
12, Dave Farley’s Response To The NONSENSE McKinsey Article On Developer Productivity – https://www.youtube.com/watch?v=yuUBZ1pByzM

Can ChatGPT accelerate No-Ops to Replace DevOps in EarlyStage Startups?

Can ChatGPT accelerate No-Ops to Replace DevOps in EarlyStage Startups?

Background: I work with multiple CTOs and Heads of Engineering of early-stage startups to help them set up their engineering orgs, review their product architecture, help them prioritise their hiring etc. I also help multiple engineering leaders via Plato. Recently, there have been too many questions on whether can I use ChatGPT for this or that, but the most interesting one among these is “Can ChatGPT accelerate No-Ops to Replace DevOps?”. I have answered that multiple times in verbatim. But thought that writing it down will help me with two things, I can point them to the URL and I can also clearly structure my thoughts on this. So this is an attempt at that.  

Glossary First:

DevOps:

For the uninitiated, DevOps is a software development methodology that emphasizes collaboration and communication between developers and operations teams. The goal of DevOps is to increase the speed and quality of software delivery while reducing errors and downtime. DevOps engineers are responsible for the design, development, and delivery of software applications, as well as the management and maintenance of the underlying infrastructure including the pipelines, quality assurance automation etc.

No-ops:

No-ops, on the other hand, is a philosophy that aims to automate and simplify the operations side of software development. The goal of no-ops is to eliminate the need for manual intervention in the deployment and maintenance of applications, freeing up time for developers to focus on creating new features and fixing bugs.

ChatGPT:

ChatGPT is a language model developed by OpenAI that has the potential to revolutionize the way we interact with technology. It can perform a wide range of tasks, from answering questions to generating text and even a rudimentary bit of coding. In the context of DevOps, ChatGPT could be used to automate many of the manual tasks that DevOps engineers currently perform, such as infrastructure management, deployment, and monitoring.

Now, The question: Can ChatGPT accelerate No-Ops to Replace DevOps?

ChatGPT (or any of the other generative AIs)  has the potential to automate many of the manual tasks performed by DevOps teams, it could potentially replace the most mundane tasks that DevOps perform pretty soon. So, before writing this piece, I wanted to actually put my understanding to test.

I had to use Bard for this experiment, but I do not think there is going to be much of a difference in the outcomes.

Experiment 1: Beginner-Level Task

Writing a simple Autoscaling script to scale as per CPU and memory utilisation.

Simple AutoScaling Script, written by Bard

Experiment 2: Intermediate-Level Task

Creation of a new VPC with 3 autoscaling groups of EC2 and 1 NAT gateway and VPC peering.

Results were mixed.

Though Bard did give information that this can be tweaked, there was one major gap between the ask and the outcome. The NAT gateway was supposed to be the single point of ingress/egress, whereas the script is entirely different.

Assume an early-stage startup that gets used to the early success of Generative AI to preempt the DevOps culture, at some point the AI won’t have the context of what all is in your infrastructure and you could end up misfiring things.

My submission is, ChatGPT or Bard or any Generative can be super helpful for a good DevOps engineer and cannot replace her/him anytime soon. In military parlance, certain materiels are termed Force Multipliers. But, they themselves cannot be the force! (Aircraft carriers or Tanker aircraft are the prime example)

Why do I believe so?

There are several reasons for this:

  1. Human creativity: Despite its advanced capabilities, ChatGPT is just another AI model and lacks the creativity and innovation that a human DevOps engineer brings to the table. DevOps engineers can think outside the box and find new and innovative solutions to “Business” problems, whereas ChatGPT operates within the constraints of its programming and is simply solving the “Constraints” for that technical problem. 
  2. Human oversight: While ChatGPT can automate many tasks, it still requires human oversight to ensure that everything is running smoothly. DevOps play a crucial role in monitoring and troubleshooting any issues that may arise during the deployment and maintenance of applications.
  3. Complexity: Many DevOps tasks are complex (or at the very least, the DevOps teams would want us to believe that) and require a deep understanding of the underlying infrastructure and applications. ChatGPT does not yet have the capability to perform these tasks at the same level of expertise as a human.
  4. Customization: Every organization has unique requirements for its development and deployment process. ChatGPT may not be able to accommodate these specific needs, whereas DevOps engineers can tailor the process to meet the non-stated requirements and organisational and platform context
  5. Responsibility: DevOps engineers are ultimately responsible for ensuring the success of the development and deployment process. While ChatGPT can assist in automating tasks, it is not capable of assuming full responsibility for the outcome.

In conclusion, while ChatGPT has the potential to automate many manual tasks performed by DevOps engineers, it is unlikely to replace DevOps entirely in the near future. The role of DevOps will continue to be important in ensuring the smooth deployment and maintenance of software applications, while ChatGPT can assist in automating certain tasks and increasing efficiency. Ultimately, the goal of both DevOps and no-ops is to increase the speed and quality of software delivery, and the use of ChatGPT in DevOps can play a significant role in achieving this goal.

References:

https://humanitec.com/whitepapers/devops-benchmarking-study-2023

Bitnami