The half-life of code & the ship of Theseus

Mike's Notes

I found this via the excellent engineering newsletter from PostHog. It's an article by Erik Bernhardsson, originally published on his blog in 2016. He has many thoughtful articles.

The article has a very enticing name.

So, what is the half-life of Pipi?

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

    The half-life of code & the ship of Theseus

    By: Erik Bernhardsson
    erikbern.com: 5/12/2016

    As a project evolves, does the new code just add on top of the old code? Or does it replace the old code slowly over time? In order to understand this, I built a little thing to analyze Git projects, with help from the formidable GitPython project. The idea is to go back in history historical and run a git blame (making this somewhat fast was a bit nontrivial, as it turns out, but I'll spare you the details, which involve some opportunistic caching of files, pick historical points spread out in time, use git diff to invalidate changed files, etc).

    In moment of clarity, I named “Git of Theseus” as a terrible pun on ship of Theseus. I'm a dad now, so I can make terrible puns. It refers to a philosophical paradox, where the pieces of a ship are replaced for hundreds of years. If all pieces are replaced, is it still the same ship?

    The ship wherein Theseus and the youth of Athens returned from Crete had thirty oars, and was preserved by the Athenians down even to the time of Demetrius Phalereus, for they took away the old planks as they decayed, putting in new and stronger timber in their places, in so much that this ship became a standing example among the philosophers, for the logical question of things that grow; one side holding that the ship remained the same, and the other contending that it was not the same.

    It turns out that code doesn't exactly evolve the way I expected. There is a “ship of Theseus” effect, but there's also a compounding effect where codebases keep growing over time (maybe I should call it “Second Avenue Subway” effect, after the construction project in NYC that's been going on since 1919).

    Let's start by analyzing Git itself. Git became self-hosting early on, and it's one of the most popular and oldest Git projects:


    This plots the aggregate number of lines of code over time, broken down into cohorts by the year added. I would have expected more of a decay here, and I'm surprised to see that so much code written back in 2006 is still alive in the code base – interesting!

    We can compute the decay for individual commits too. If we align all commits at x=0, we can look at the aggregate decay for code in a certain repo. This analysis is somewhat harder to implement than it sounds like because of various stuff (mostly because newer commits have had less time, so the right end of the curve represents an aggregate of fewer commits).

    For Git, this plot looks like this:


    Even after 10 years, 40% of lines of code is still present! Let's look at a broader range of (somewhat randomly selected) open source projects:


    It looks like Git is somewhat of an outlier here. Fitting an exponential decay to Git and solving for the half-life gives approx ~6 years.


    Hmm… not convinced this is necessarily a perfect fit, but as the famous quote goes: All models are wrong, some models are useful. I like the explanatory power of an exponential decay – code has an expected life time and a constant risk of being replaced.

    I suspect a slightly better model would be to fit a sum of exponentials. This would work for a repo with some code that changes fast and some code that changes slowly. But before going down a rabbit hole of curve fitting, I reminded myself of von Neumann's quote: With four parameters I can fit an elephant, and with five I can make him wiggle his trunk. There's probably some way to make it work, but I'll revisit some other time.

    Let's look at a lot of projects in aggregate (also sampled somewhat arbitrarily):


    In aggregate, the half-life is roughly ~3.33 years. I like that, it's an easy number to remember. But the spread is big between different projects. The aggregate model doesn't necessarily have super strong predictive power – it's hard to point to a arbitrary open source project and expect half of it to be gone 3.33 years later.

    Moar repos

    Apache (aka HTTPD) is another repo that goes way back:

    Rails:




    Beautiful exponential fit!

    Node:



    Wanna run it for your own repo? Again, code is available here.

    The monster repo of them all

    Note that most of these repos took at most a few minutes to analyze, using my script. As a final test I decided to run it over the Linux kernel which is HUGE – 635,229 commits as of today. This is 16 times larger than the second biggest repo I looked at (rails) and took multiple days to analyze on my shitty computer. To make it faster I ended up computing the full git blame only for commits spread out at least 3 weeks and also limited it to .c files:


    The squiggly lines are probably from the sampling mechanism. But look at this beauty – a whopping 16M lines! The code contribution from each year's cohort is extremely smooth at this scale. Individual commits have absolutely no meaning at this scale – they cumulative sum of them is very predictible. It's like going from Newton's laws to thermodynamics.


    Linux also clearly exhibits more of a linear growth pattern. I'm speculating that this has to do with its high modularity. The drivers directory has by far the most number of files (22,091) followed by arch (17,967) which contains support for various architectures. This is exactly the kind of things you would expect to scale very well with complexity, since they have a well defined interface.

    Somewhat off topic, but I like the notion of how well a projects scales with complexity. A linear scalability is the ultimate goal, where each one marginal feature takes roughly the same amount of code. Bad projects scale superlinearly, and every marginal feature takes more and more code.

    It's interesting to go back and contrast Linux to something like Angular, which basically exhibits the opposite behavior:



    The half-life of a randomly selected line in Angular is about 0.32 years. Does this reflect on Angular? Is the architecture basically not as “linear” and consistent? You might say the comparison is unfair, because Angular is new. That's a fair point. But I wouldn't be surprised if it does reflect on some questionable design. Don't mean to be shitting on Angular here, but it's an interesting contrast.

    Half-life by repository

    A somewhat arbitrary sample of projects and their half-lifes:

    Project Half-life (years) First Commit
    angular 0.32 2014
    bluebird 0.56 2013
    kubernetes 0.59 2014
    keras 0.69 2015
    tensorflow 1.08 2015
    express 1.23 2009
    scikit-learn 1.29 2011
    luigi 1.3 2012
    backbone 1.48 2010
    ansible 1.52 2012
    react 1.66 2013
    node 1.76 2009
    underscore 1.97 2009
    requests 2.1 2011
    rails 2.43 2004
    django 3.38 2005
    theano 3.71 2008
    numpy 4.15 2006
    moment 4.54 2015
    scipy 4.62 2007
    tornado 4.8 2009
    redis 5.2 2010
    flask 5.22 2010
    httpd 5.38 1999
    git 6.04 2005
    chef 6.18 2008
    linux 6.6 2005

    It's interesting that moment has such high half-life, but the reason is that so much of the code is locale-specific. This creates a more linear scalability with a stable core of code and linear additions over time. express is an outlier in the other direction. It's 7 years old but code changes extremely quickly. I'm guessing this is partly because (a) lack of linear scalability in code (b) it's probably one of the first major Javascript open source projects to hit mainstream/popularity, surfing on the Node.js wave. Possibly the code base also sucks, but I have no idea 😊

    Has coding changed?

    I can think of three reasons why there's such a strong relationship between the year the project was initiated, and the half-life

    1. Code churns more early on in projects, and becomes more stable a while in
    2. Coding has changed from 2006 to 2016, and modern projects evolve faster
    3. There's some kind of selection bias where the only projects that survive are the scalable stable ones

    Interestingly, I don't find any clear evidence of #1 in the data. The half-life for code written earlier in old projects are as high as late code. I'm skeptical about #3 as well because I don't see why there would be a relation between survival and code structure (but maybe there is). My conclusion is that writing code has fundamentally changed in the last 10 years. Code really seems to change at a much faster rate in modern projects.

    By the way, see discussion on Hacker News and on Reddit!

    AWS Reveals Multi-Agent Orchestrator Framework for Managing AI Agents

    Mike's Notes

    Some interesting examples of orchestrating AI agents.

    The article copied below is from InfoQ and is by Daniel Dominguez.

    Pipi 9 has an agent orchestrator called the Conductor Engine (cnd), so I am interested in comparing all these examples to get more insights and make a few improvements.

    Resources

    References


    Repository

    • Home > Ajabbi Research > Library >
    • Home > Handbook >

    Last Updated

    17/05/2025

    AWS Reveals Multi-Agent Orchestrator Framework for Managing AI Agents

    By: Daniel Dominguez
    InfoQ: 02/12/2024

    AWS has introduced Multi-Agent Orchestrator, a framework designed to manage multiple AI agents and handle complex conversational scenarios. The system routes queries to the most suitable agent, maintains context across interactions, and integrates seamlessly with a variety of deployment environments, including AWS Lambda, local setups, and other cloud platforms.

    The framework supports dual-language implementation in Python and TypeScript and accommodates both streaming and non-streaming agent responses. It includes pre-built agents for rapid deployment and provides extensive features such as intelligent intent classification, robust context management, and the scalability to integrate new agents or customize existing ones. This makes it a versatile tool for enterprises managing diverse AI applications.

    The high-level architecture diagram illustrates the process starting with the user input, which is analyzed by a Classifier. This Classifier uses both the characteristics of the agents and their conversation history to determine the most appropriate agent for the task. Once the agent is selected, it processes the user input, and the orchestrator updates the agent’s conversation history before delivering the response back to the user.

    AWS has also published a demo application showcasing the orchestrator’s capabilities. The demo includes six specialized agents, such as those for travel, weather, math, and health. These agents demonstrate the system's ability to seamlessly switch between tasks and maintain coherence in multi-turn conversations. Additional projects, such as a multilingual chatbot for flight reservations and an AI-powered e-commerce support system, highlight the framework's flexibility in addressing specialized use cases.

    Beyond text-based interactions, the orchestrator supports voice-based systems by integrating with tools like Amazon Connect and Lex. This capability enhances its application for AI-driven customer service, call centers, and other domains requiring natural language and voice interaction.

    In the community, the launch has generated interest from key figures in AI and ML.

    Bob Xu, founder of Quest Flow, a company specializing in multi-agent orchestration, commented on X, stating:

    "Multi-agent is going mainstream now."

    And AI/ML tech sourcer Jung Kim shared on X:

    "AWS Labs' Multi-Agent Orchestrator open source project rethinks distributed computing to make it easier to build sophisticated, efficient, and cost-effective AI systems."

    AWS's Multi-Agent Orchestrator launches as part of the growing trend towards agent-based AI systems. Other frameworks in this space include Microsoft Research's Magentic-One, a generalist multi-agent system for solving open-ended tasks, and IBM's Bee Agent Framework, designed for scalable, agent-based workflows. OpenAI has also introduced Swarm, a system focused on building and deploying multi-agent configurations. These frameworks collectively reflect an industry-wide effort to enhance the orchestration and efficiency of multi-agent AI deployments.

    DeepSeek Debates: Chinese Leadership On Cost, True Training Cost, Closed Model Margin Impacts

    Mike's Notes

    This excerpt from a recent article from SemiAnalysis sheds more light on the recent AI hype. DeepSeek is a significant improvement, but not everything seems as good.

    The full article requires a login to SemiAnalysisResources.

    I have also added some other articles to the references.

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library > Subscriptions > SemiAnalysis
    • Home > Handbook > 

    Last Updated

    17/05/2025

    DeepSeek Debates: Chinese Leadership On Cost, True Training Cost, Closed Model Margin Impacts

    By: Dylan Patel, AJ Kourabi, Doug O'Laughlin, Reyk Knuhtsen
    SemiAnalysis: 31/01/2025

    The DeepSeek Narrative Takes the World by Storm

    DeepSeek took the world by storm. For the last week, DeepSeek has been the only topic that anyone in the world wants to talk about. As it currently stands, DeepSeek daily traffic is now much higher than Claude, Perplexity, and even Gemini.

    But to close watchers of the space, this is not exactly “new” news. We have been talking about DeepSeek for months (each link is an example). The company is not new, but the obsessive hype is. SemiAnalysis has long maintained that DeepSeek is extremely talented and the broader public in the United States has not cared. When the world finally paid attention, it did so in an obsessive hype that doesn’t reflect reality.

    We want to highlight that the narrative has flipped from last month, when scaling laws were broken, we dispelled this myth, now algorithmic improvement is too fast and this too is somehow bad for Nvidia and GPUs.

    The narrative now is that DeepSeek is so efficient that we don't need more compute, and everything has now massive overcapacity because of the model changes. While Jevons paradox too is overhyped, Jevons is closer to reality, the models have already induced demand with tangible effects to H100 and H200 pricing.

    DeepSeek and High-Flyer

    High-Flyer is a Chinese Hedge fund and early adopters for using AI in their trading algorithms. They realized early the potential of AI in areas outside of finance as well as the critical insight of scaling. They have continuously increasing their supply of GPUs as a result. After experimentation with models with clusters of thousands of GPUs, High Flyer made an investment in 10,000 A100 GPUs in 2021 before any export restrictions. That paid off. As High-Flyer improved, they realized that it was time to spin off “DeepSeek” in May 2023 with the goal of pursuing further AI capabilities with more focus. High-Flyer self funded the company as outside investors had little interest in AI at the time, with the lack of a business model being the main concern. High-Flyer and DeepSeek today often share resources, both human and computational.

    DeepSeek now has grown into a serious, concerted effort and are by no means a “side project” as many in the media claim.  We are confident that their GPU investments account for more than $500M US dollars, even after considering export controls.

    Source: SemiAnalysis, Lennart Heim

    The GPU Situation

    We believe they have access to around 50,000 Hopper GPUs, which is not the same as 50,000 H100, as some have claimed. There are different variations of the H100 that Nvidia made in compliance to different regulations (H800, H20), with only the H20 being currently available to Chinese model providers today. Note that H800s have the same computational power as H100s, but lower network bandwidth. We believe DeepSeek has access to around 10,000 of these H800s and about 10,000 H100s. Furthermore they have orders for many more H20's, with Nvidia having produced over 1 million of the China specific GPU in the last 9 months. For more specific detailed analysis, please refer to our Accelerator Model.

    Source: SemiAnalysis

    Our analysis shows that the total server CapEx for DeepSeek is almost $1.3B, with a considerable cost of $715M associated with operating such clusters.

    DeepSeek has sourced talent exclusively from China, with no regard to previous credentials, placing a heavy focus on capability and curiosity. DeepSeek regularly runs recruitment events at top universities like PKU and Zhejiang, where many of the staff graduated from. Roles are not necessarily pre-defined and hires are given flexibility, with jobs ads even boasting of access to 10,000s GPUs with no usage limitations. They are extremely competitive, and allegedly offer salaries of over $1.3 million dollars USD for promising candidates, well a over big Chinese tech companies. They have ~150 employees, but are growing rapidly.

    As history shows, a small well-funded and focused startup can often push the boundaries of what’s possible. DeepSeek lacks the bureaucracy of places like Google, and since they are self funded can move quickly on ideas. However, like Google, DeepSeek (for the most part) runs their own datacenters, without relying on an external party or provider. This opens up further ground for experimentation, allowing them to make innovations across the stack.

    We believe they are the single best “open weights" lab today, beating out Meta’s Llama effort, Mistral, and others.

    DeepSeek’s Cost and Performance

    DeepSeek’s price and efficiencies caused the frenzy this week, with the main headline being the “$6M” dollar figure training cost of DeepSeek V3. This is wrong. This akin to pointing to a specific (and large) part of a bill of materials and attribute it as the entire cost. The pre-training cost is a very narrow portion of the total cost.

    Training Cost

    We believe the pre-training number is nowhere near close to the actual amount spent on the model. We are confident their hardware spend is well higher than $500M over the company history. To develop new architecture innovations, during the model development, there is a considerable spend on testing new ideas, new architecture ideas, and ablations. Multi-Head Latent Attention, a key innovation of DeepSeek, took several months to develop and cost a whole team of manhours and GPU hours.

    The $6M cost in the paper is attributed to just the GPU cost of the pre-training run, which is only a portion of total cost of the model. Excluded are important pieces of the puzzle like R&D and TCO of the hardware itself. For reference, Claude 3.5 Sonnet cost $10s of millions to train, and if that was the total cost Anthropic needed, then they would not raise billions from Google and tens of billions from Amazon. It's because they have to experiment, come up with new architectures, gather and clean data, pay employees, and much more.

    So how was DeepSeek able to have such a large cluster? The lag in export controls is the key, and will be discussed in the export section below.

    Closing the Gap - V3’s Performance

    V3 is no doubt an impressive model, but it is worth highlighting impressive relative to what. Many have compared V3 to GPT-4o and highlight how V3 beats the performance of 4o. That is true but GPT-4o was released in May of 2024. AI moves quickly and May of 2024 is another lifetime ago in algorithmic improvements. Further we are not surprised to see less compute to achieve comparable or stronger capabilities after a given amount of time. Inference cost collapsing is a hallmark of AI improvement.

    Source: SemiAnalysis

    An example is small models that can be run on laptops have comparable performance to GPT-3, which required a supercomputer to train and multiple GPUs to inference. Put differently, algorithmic improvements allow for a smaller amount of compute to train and inference models of the same capability, and this pattern plays out over and over again. This time the world took notice because it was from a lab in China. But smaller models getting better is not new.

    Source: SemiAnalysis, Artificialanalysis.ai, Anakin.ai, a16z

    So far what we've witnessed with this pattern is that AI labs spend more in absolute dollars to get even more intelligence for their buck. Estimates put algorithmic progress at 4x per year, meaning that for every passing year, 4x less compute is needed to achieve the same capability. Dario, CEO of Anthropic arguea that algorithmic advancements are even faster and can yield a 10x improvement. As far as inference pricing goes for GPT-3 quality, costs have fallen 1200x.

    When investigating the cost for GPT-4, we see a similar decrease in cost, although earlier in the curve. While the decreased difference in cost across time can be explained by no longer holding the capability constant like the graph above. In this case, we see algorithmic improvements and optimizations creating a 10x decrease in cost and increase in capability.

    Source: SemiAnalysis, OpenAI, Together.ai

    To be clear DeepSeek is unique in that they achieved this level of cost and capabilities first. They are unique in having released open weights, but prior Mistral and Llama models have done this in the past too. DeepSeek has achieved this level of cost but by the end of the year do not be shocked of costs fall another 5x.

    Is R1’s Performance Up to Par with o1?

    On the other hand, R1 is able to achieve results comparable to o1, and o1 was only announced in September. How has DeepSeek been able to catch so fast?

    The answer is that reasoning is a new paradigm with faster iteration speeds and lower hanging fruit with meaningful gains for smaller amounts of compute than the previous paradigm. As outlined in our scaling laws report, the previous paradigm depended on pre-training, and that is becoming both more expensive and difficult to achieve robust gains with.

    The new paradigm, focused on reasoning capabilities through synthetic data generation and RL in post-training on an existing model, allows for quicker gains with a lower price. The lower barrier to entry combined with the easy optimization meant that DeepSeek was able to replicate o1 methods quicker than usual. As players figure out how to scale more in this new paradigm, we expect the time gap between matching capabilities to increase.

    Note that the R1 paper makes no mention of the compute used. This is not an accident – a significant amount of compute is needed to generate synthetic data for post-training R1. This is not to mention RL. R1 is a very good model, we are not disputing this, and catching up to the reasoning edge this quickly is objectively impressive. The fact that DeepSeek is Chinese and caught up with less resources makes it doubly impressive.

    But some of the benchmarks R1 mention are also misleading. Comparing R1 to o1 is tricky, because R1 specifically doesn't mention benchmarks that they are not leading in. And while R1 is matches reasoning performance, it's not a clear winner in every metric and in many cases it is worse than o1.


    Source: (Yet) another tale of Rise and Fall: DeepSeek R1

    And we have not mentioned o3 yet. o3 has significantly higher capabilities than both R1 or o1. In fact, OpenAI recently shared o3’s results, and the benchmark scaling is vertical. "Deep learning has hit a wall", but of a different kind.

    Source: AI Action Summit

    Google’s Reasoning Model is as Good as R1

    While there is a frenzy of hype for R1, a $2.5T US company released a reasoning model a month before for cheaper: Google’s Gemini Flash 2.0 Thinking. This model is available for use, and is considerably cheaper than R1, even with a much larger context length for the model through API.

    On reported benchmarks, Flash 2.0 Thinking beats R1, though benchmarks do not tell the whole story. Google only released 3 benchmarks so it's an incomplete picture. Still, we think Google’s model is robust, standing up to R1 in many ways while receiving none of the hype. This could be because of Google’s lackluster go to market strategy and poor user experience, but also R1 is a Chinese surprise. 


    Source: SemiAnalysis

    To be clear, none of this detracts from DeepSeek’s remarkable achievements. DeepSeek’s structure as a fast moving, well-funded, smart and focused startup is why it's beating giants like Meta in releasing a reasoning model, and that's commendable.

    Technical Achievements

    DeepSeek has cracked the code and unlocked innovations that leading labs have not yet been able to achieve. We expect that any published DeepSeek improvement will be copied by Western labs almost immediately.  

    What are these improvements? Most of the architectural achievements specifically relate to V3, which is the base model for R1 as well. Let’s detail these innovations.

    Training (Pre and Post)

    DeepSeek V3 utilizes Multi-Token Prediction (MTP) at a scale not seen before, and these are added attention modules which predict the next few tokens as opposed to a singular token. This improves model performance during training and can be discarded during inference. This is an example of an algorithmic innovation that enabled improved performance with lower compute.   

    There are added considerations like doing FP8 accuracy in training, but leading US labs have been doing FP8 training for some time.

    DeepSeek v3 is also a mixture of experts model, which is one large model comprised of many other smaller models that specialize in different things. One struggle MoE models have faced has been how to determine which token goes to which sub-model, or “expert”. DeepSeek implemented a “gating network” that routed tokens to the right expert in a balanced way that did not detract from model performance. This means that routing is very efficient, and only a few parameters are changed during training per token relative to the overall size of the model. This adds to the training efficiency and to the low cost of inference.

    Despite concerns that Mixture-of-Experts (MoE) efficiency gains might reduce investment, Dario points out that the economic benefits of more capable AI models are so substantial that any cost savings are quickly reinvested into building even larger models. Rather than decreasing overall investment, MoE's improved efficiency will accelerate AI scaling efforts. The companies are laser focused on scaling models to more compute and making them more efficient algorithmically.             

    In terms of R1, it benefited immensely from having a robust base model (v3). This is partially because of the Reinforcement Learning (RL). There were two focuses in RL: formatting (to ensure it provides a coherent output) and helpfulness and harmlessness (to ensure the model is useful). Reasoning capabilities emerged during the fine-tuning of the model on a synthetic dataset. This, as mentioned in our scaling laws article, is what happened with o1. Note that in the R1 paper no compute is mentioned, and this is because mentioning how much compute was used would show that they have more GPUs than their narrative suggests. RL at this scale requires a considerable amount of compute, especially to generate synthetic data.

    Additionally a portion of the data DeepSeek used seems to be data from OpenAI’s models, and we believe that will have ramifications on policy on distilling from outputs. This is already illegal in the terms of service, but going forward a new trend might be a form of KYC (Know Your Customer) to stop distillation.  

    And speaking of distillation, perhaps the most interesting part of the R1 paper was being able to turn non-reasoning smaller models into reasoning ones via fine tuning them with outputs from a reasoning model. The dataset curation contained a total of 800k samples, and now anyone can use R1’s CoT outputs to make a dataset of their own and make reasoning models with the help of those outputs. We might see more smaller models showcase reasoning capabilities, bolstering performance of small models.

    Multi-head Latent Attention (MLA)

    MLA is a key innovation responsible for a significant reduction in the inference price for DeepSeek. The reason is MLA reduces the amount of KV Cache required per query by about 93.3% versus standard attention. KV Cache is a memory mechanism in transformer models that stores data representing the context of the conversation, reducing unnecessary computation.

    As discussed in our scaling laws article, KV Cache grows as the context of a conversation grows, and creates considerable memory constraints. Drastically decreasing the amount of KV Cache required per query decreases the amount of hardware needed per query, which decreases the cost. However we think DeepSeek is providing inference at cost to gain market share, and not actually making any money. Google Gemini Flash 2 Thinking remains cheaper, and Google is unlikely to be offering that at cost. MLA specifically caught the eyes of many leading US labs. MLA was released in DeepSeek V2, released in May 2024.

    DeepSeek has also enjoyed more efficiencies under inference with the H20, due to higher memory and bandwidth capacity compared to the H100. They have also announced partnerships with Huawei but very little has been done with them so far with Ascend compute.

    We believe the most interesting implications is specifically on margins, and what that means for the entire ecosystem. Below we have a view of the future pricing structure of the entire AI industry, and we detail why we think DeepSeek is subsidizing price, as well as why we see early signs that Jevons paradox is carrying the day. We comment on the implications on export controls, how the CCP might react with added DeepSeek domninance, and more.

    Super Colour Palette

    Mike's Notes

    Dave Gray from Explorations and Explanations mentioned this great tool in his recent Substack. It allows you to choose a colour palette that can be exported.

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library >
    • Home > Handbook > 
    • Home > Ajabbi Design > Design System > Colour

    Last Updated

    17/05/2025

    Super Colour Palette

    By: Dave Gray
    Explorations and Explanations: 07/02/2025

    The Four Team Types from Team Topologies

    Mike's Notes

    More on how to organise IT developers into teams.

    Resources

    References

    • Team Topologies: Organizing Business and Technology Teams for Fast Flow

    Repository

    • Home > Ajabbi Research > Library >
    • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
    • Home > Handbook > Teams

    Last Updated

    17/05/2025

      The Four Team Types from Team Topologies

      By: IT Revolution
      IT Revolution: February 23, 2023

      In many organizations, especially at the enterprise level, there are many types of teams, even teams who take on multiple roles. As the organization continues to grow and these team types continue to sprawl, it becomes increasingly hard to visualize the full organizational landscape, and, consequently, to get things done.

      One of the most important things to remember, is that we can be intentional about how we build and organize teams. We can design our teams and our organization for the results we want (Conway’s Law).

      So what does this intentional organization look like? The idea of organizing a company of hundreds, thousands, or even tens of thousands of people is daunting.

      But, according to the research of Matthew Skelton and Manuel Pais, there are really only four fundamental team types.

      What are the Four Team Types?

      When used well, these four team topologies are the only team types you need to build and run modern software systems.

      • Stream-Aligned Team
      • Enabling Team
      • Complicated-Subsystem Team
      • Platform Team

      As Matthew and Manuel say in their bestselling book Team Topologies: Organizing Business and Technology Teams for Fast Flow,

      "When these four team types are combined with effective software boundaries and team interactions, the restriction of these four team types acts as a powerful template for effective organization design." - Team Topologies: Organizing Business and Technology Teams for Fast Flow

      Let’s dive into what each of these teams is in more detail.

      Stream-Aligned Teams

      A “stream” is the continuous flow of work aligned to a single business domain or org capability. A stream-aligned team is aligned to a single, valuable stream of work like a single product or service, a set of features, or even a user journey or user persona. This team is empowered to build and deliver value quickly, safely, and (this is key) independently. There shouldn’t be any hand-offs to other teams to complete parts of the work. They “own” it from beginning to end.

      Stream-aligned teams should be the primary team type in an organization. All other team types exist to reduce the burden on stream-aligned teams.

      Stream-aligned teams should be close to the customer so they can quickly incorporate feedback and monitor their software in production. This allows the stream-aligned team to react in near real-time and adapt to changes as needed. They are quick, agile, dedicated.

      Enabling Teams

      An enabling team bridges the capability gap. In Accelerate, we learn that high-performing teams are continuously improving their capabilities to stay ahead of the curve. This is difficult when you have end-to-end ownership of a value stream (as in stream-aligned teams). With all that work, it can be hard to find the time for research, learning, and practising new skills.

      Enabling teams are composed of specialists in a given domain of knowledge, which might be more technical, or more product-focused, or any other domain where there is a gap in skills in (part of) the organization. They cross-cut to stream-aligned teams and have the bandwidth for research, experimentation, etc. They bring this knowledge and expertise back to the stream-aligned team.

      A successful enabling team should be strongly collaborative in nature. They must work to understand the problems faced by the stream-aligned team and then provide proper guidance. Enabling teams must avoid becoming an “ivory tower” of knowledge. They do not exist to dictate technical choices. Instead, an enabling team helps stream-aligned teams understand and comply with organization-wide constraints. They are the “servant leaders” of the team types.

      Complicated-Subsystem Teams

      The complicated-subsystem team is responsible for building and maintaining a system that requires heavy specialist knowledge. Each member on the team should be a specialist in that area of knowledge and be able to make changes to the subsystem.

      The goal of the complicated-subsystem team is to reduce the cognitive load of stream-aligned teams working on the system. This is more cost effective than embedding a specialist onto every stream-aligned team, and avoids distracting the stream-aligned team from their main goal of delivery value.

      Platform Teams

      A platform team enables a stream-aligned team to deliver work with substantial autonomy by providing internal services to reduce their cognitive load. A digital platform, as defined by Evan Bottcher, is

      ". . . a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination." -https://martinfowler.com/articles/talk-about-platforms.html

      The platform team’s knowledge is made available via self-service capabilities on the web or via a programmable API. These should be made easy for the stream-aligned teams to consume, instead of lengthy instruction manuals.

      Ease of use is fundamental to successful product teams.

      The Benefit of Restricting Team Types

      Organizations that are struggling with rapid, sustainable software delivery typically have a wide and ever-expanding group of teams and team types. Usually these teams have poorly defined roles and responsibilities. By restricting teams to just the four fundamental types explored in the post and expanded upon in the book Team Topologies, the organization can focus their time on team interaction patterns that are known to promote flow and deliver value faster.

      We’ll explore the three essential team interaction modes in an upcoming post.

      Building High-Performing Teams with Team Topologies

      Mike's Notes

      This thoughtful article about team structure is from Leah Brown, the Managing Editor at IT Revolution. Pipi 9 is specifically built for high-performance DevOps teams building big enterprise SaaS systems.

      The book Team Topologies has a reader's guide.

      Resources

      References

      • Reference

      Repository

      • Home > Ajabbi Research > Library >
      • Home > Handbook > 

      Last Updated

      17/05/2025

      Building High-Performing Teams with Team Topologies

      By: Leah Brown
      IT Revolution: January 13 2025

      To achieve success and rise above competitors in 2025, organizations must focus on building high-performance teams. One strategy to do this is to empower small, long-lived teams as the fundamental building blocks of your organization’s design. 

      As we looked at in the previous blog in our series on high-performing teams, building high-performance teams has less to do with where your teams sit and more with how you build the social circuitry between and within teams. The Team Topologies approach provides a proven framework for designing and evolving these teams to maximize flow and adaptability.

      Limit Team Cognitive Load

      A core tenet of Team Topologies is that teams should minimize cognitive load to increase flow. This can be achieved by ensuring a team is only responsible for a limited number of domains, projects, software subsystems, products, etc. that match their cognitive capacity. By restricting teams to a maximum of 2-3 “simple” domains or 1 “complicated” domain, organizations can ensure teams have the focus and autonomy to truly master their areas of responsibility. 

      This team-first approach to organizational boundaries stands in contrast to the traditional practice of aligning teams to organizational silos or technical specialties. Instead, work is divided into pieces that fit the team’s cognitive load, creating a natural correspondence between the team structure and the larger system or organization architecture.

      Establish Clear Team Interactions

      Beyond structuring teams, Team Topologies also emphasize defining well-bounded interactions between teams. Clear and effective communication has long been a differentiator in high-performing organizations, but it can be challenging to achieve in sprawling enterprises. 

      One way to build effective communications is to establish “team APIs” that establish clearly and visibly how other teams can interact with a given team’s code, documentation, and working practices. This also means consciously designing the physical and virtual spaces that enable appropriate levels of collaboration, from high bandwidth within teams to low bandwidth between most teams.

      By creating these structured team interactions, organizations can reduce cognitive load, promote autonomy, and ensure smooth handoffs between dependent teams. This paves the way for sustainable, high-velocity flow of value to the customer.

      Evolve Team Topologies over Time

      Of course, projects and organizational contexts are constantly shifting. Perhaps at no time has that been more true than now. How many times in the past week have you seen or read the phrase “in these rapidly changing times”? The Team Topologies approach embraces this by providing guidance on evolving team structures and interactions in response to changing requirements. This is also a key differentiator of the highest-performing teams and organizations: the ability to adapt to changing situations quickly and confidently.

      This can be achieved by splitting a team responsible for too many domains or projects, merging teams with overlapping responsibilities, or introducing new team types like “enabling” or “platform” teams to support the core “stream-aligned” delivery teams.

      The key is maintaining a dynamic, adaptive organizational design that keeps pace with the business. Just a year ago, implementing AI in daily operations was still a rarity. But today, organizations are adopting AI into their work at a dizzying pace. Teams and organizations that can adjust and adapt to this new context with skill and confidence will surely outperform those that are built more rigid.

      The Human Element

      Ultimately, the Team Topologies approach recognizes that knowledge work, like software delivery, is a deeply human endeavor. By optimizing team size, boundaries, and interactions, organizations can create the conditions for small, autonomous groups to thrive and deliver exceptional results, even in the face of exceptional change. This team-centric focus is the foundation for sustainable, high-performing teams in 2025 and beyond.

      Kubernetes Cloud Repatriation Saves Millions for Data Platform Provider

      Mike's Notes

      This is a good example of the savings possible from using a private cloud. I suggest putting the core of Pipi9 on a private cloud to control costs, the environment, and security.

      Resources

      References

      • Reference

      Repository

      • Home > Ajabbi Research > Library > Subscriptions > InfoQ
      • Home > Handbook > 

      Last Updated

      17/05/2025

      Kubernetes Cloud Repatriation Saves Millions for Data Platform Provider

      By: Matt Saunders
      InfoQ: 29/01/2025

      Yellowbrick, an SQL data platform provider, has significantly reduced costs by moving workloads from the public cloud to its own private Kubernetes-based infrastructure. It has reported an annual saving of $3.9 million by moving its development and testing environments away from AWS, Azure, and Google Cloud Platform.

      According to Neil Carson of Yellowbrick, the company had been spending about $6 million per year across the three major cloud providers when the repatriation project began in 2022. Yellowbrick built its new private cloud using hardware that had previously been used for another purpose within the company. The company traditionally sells appliances to run its database product on, and it realised it could reuse these appliances when its customers upgraded and returned the older servers.

      '"We thought elasticity in the cloud had to be cheaper than building appliances, but we found out the hard way, it wasn't cheaper. It was much more expensive" - Neil Carson, Yellowbrick

      The private cloud solution, named EC3 (Emerald City), uses two types of racks: compute racks and object storage racks. The system employs MinIO for object storage and LINSTOR for persistent block storage, running on a complex networking setup that utilises InfiniBand networking.

      The current EC3 deployment consists of over 200 servers returned by their customers, providing over 8,000 vCPUs and about  2 petabytes of object storage. The primary ongoing cost is $50,000 per month in colocation facility fees in Utah. In comparison, Carson estimates that equivalent capacity on AWS would cost them around $375,000 per month.

      Yellowbrick's cloud spend per month

      Image courtesy of Neil Carson, Yellowbrick

      The transition wasn't without its challenges. The initial implementation needed dedicated focus, with the equivalent of two full-time engineers working on it for six months. However, now the cloud is live, ongoing administration needs a couple of developers to spend a few hours weekly on maintenance. The company reports that regular hardware failures occur approximately every couple of weeks, leading to plans for implementing automated problem detection systems.

      While Yellowbrick's situation is unusual due to the availability of returned paid-off hardware at effectively zero capital cost, Carson suggests that companies starting from scratch could still see substantial savings. He estimates that the initial capital expenditure for new equipment would be approximately $1.65 million, including $1.3 million for compute, $80,000 for switching and cables, and $270,000 for SSD storage.

      The success of EC3 has influenced Yellowbrick's product development. Their third-generation appliances, codenamed Griffin, will be powered by RedHat OpenShift and incorporate lessons learned from building the private cloud infrastructure. The company's experience suggests that Kubernetes has become a game-changer in the infrastructure space. As Carson explains, "All the elasticity, scale up/down, and flexibility that used to require the public cloud can now be done on equipment we own, too."

      Carson acknowledges that advocating for on-premises solutions remains controversial in the tech industry. "When I've heard others trying to share these viewpoints, they have been accused of lying, not calling out hidden costs, being backward, etc.," he writes. However, he maintains that for compute-intensive workloads, the financial benefits of repatriating are clear.

      The repatriation initiative came to the world's attention with a well-publicised move of David Heinemeier Hansson's HEY and Basecamp infrastructure out of the cloud in 2022, demonstrating that consistent and non-spiky CPU-intensive workloads can often be run at a significant discount on customer's own equipment.

      A recent blog post from Puppet details why some organisations choose to move some workloads away from the public cloud. Cost is still a primary driver, with organisations seeing increased costs across computing, storage, and data transfer. Security and compliance are also big factors, with some choosing to repatriate workloads to avoid having to answer complex questions about data storage locations, access controls, and regulatory compliance across multiple cloud environments.

      Why Cloud Repatriation is Trending

      Puppet also explains how performance limitations have prompted some companies to look away from public clouds, especially for workloads needing low latency. Also, some organisations are concerned about the risk of vendor lock-in and don't want to depend on specific providers for their software, platform, or infrastructure needs.

      The Puppet article also raises technical challenges unique to the public cloud - such as accidental misconfigurations potentially having drastic consequences (citing a 2022 incident where a single AWS S3 bucket misconfiguration exposed millions of sensitive files).

      Despite the significant advantage of having a pool of returned servers to repurpose, the success of Yellowbrick's private cloud implementation adds to a growing body of evidence that some companies, particularly those with predictable compute-intensive workloads, may benefit from evaluating alternatives to public cloud services.

      Creating Accessible Websites Using the Web Content Accessibility Guidelines

      Mike's Notes

      A great introduction to WCAG.

      Resources

      References

      • Reference

      Repository

      • Home > Ajabbi Research > Library >
      • Home > Handbook > 

      Last Updated

      17/05/2025

      Creating Accessible Websites Using the Web Content Accessibility Guidelines

      By: Ben Linders
      InfoQ: 30/01/2025

      Web accessibility is about making web content available to users with disabilities. Development teams can use the success criteria of the Web Content Accessibility Guidelines to improve accessibility and create an inclusive website.

      Joanna Falkowska gave a talk about creating accessible websites at DEV: Challenge Accepted.

      There are different kinds of disabilities, Falkowska said. Think of users with sensory limitations (e.g. visual, hearing), physical ones (e.g. missing limbs), neurological diseases (e.g. Parkinson’s disease), or cognitive disability (e.g. Down syndrome).

      The WHO estimates that about 16% of the world’s population is affected by significant disability:

      "If we add all of the mild ones, as well as groups that usually do not consider themselves disabled but might be facing similar problems, such as the elderly, the number becomes even higher."

      Falkowska mentioned that development teams who do not know where to start their accessibility journey may feel overwhelmed by the number of disabilities they should take into consideration. They may have no idea about the limitations different users with disabilities face when opening their web app:

      "What they need is a benchmark that gives them clear criteria as to what makes an app accessible."

      The Web Content Accessibility Guidelines (WCAG) is a document that serves people who create web apps. It has been drafted to make the web accessible and it gets updated every now and then to keep up with the development of the technology people use, Falkowska said. Just as the offline world can be more or less friendly for people with disabilities, the same way the websites that we browse can be more or less accessible, she added.

      The WCAG gives you a set of success criteria that have assigned conformance levels, as Falkowska explained:

      The lowest and the most basic one is A. The Web Accessibility Initiative (WAI), who is responsible for drafting and updating WCAG, states that any website we browse should address at least this level of conformance.

      AA is a bit more complex, but at the same time it is the level that the authors (and many legal acts) recommend to follow, Falkowska said. The third and generally the most difficult to achieve is AAA. Usually the entities that address triple A will either be governmental/federal offices or companies/associations that serve specific groups of people with disabilities, Falkowska mentioned.

      The levels are a bit like the wooden nesting doll "matryoshka", Falkowska said; if you want to address AAA with your website, you also need to cover AA as well as A’s success criteria.

      Falkowska mentioned that one of the most commonly missing success criteria tells you to add alternative text to any content that makes sense only if you can perceive it with your eyes. For example, if your website contains an image, a person who cannot see and uses a screen reader will only hear the name of the file, which may just be a meaningless string of numbers and characters. In order to make sure they can perceive this content in a meaningful way, developers add an "alt" attribute in html, Falkowska said. The content of this attribute will not be visible on the website, but the screen reader will read it to a person using assistive technology.

      InfoQ interviewed Joanna Falkowska about the success criteria for an accessible website.

      InfoQ: Can you give some examples of success criteria?

      "Joanna Falkowska: An example would be keyboard focus. It should be possible for the user to navigate all of the interactive elements with a keyboard, which is achieved with the "tabindex" attribute in html. It is beneficial not only for users with visual disabilities, but also to those who cannot use a mouse due to hand tremors, e.g. because of Parkinson’s disease. It is also a very good example of how a success criterion may support users without disability. I cannot count the number of situations when my mouse was discharged and I needed to navigate the web with a keyboard only while waiting for the mouse battery to fill up...

      Another example is that of screen orientation (which is mainly important for tablets and smartphones). It should not be limited to landscape or portrait-only mode. Some users may use a mobile device in one orientation only. Think of the users with quadriplegia who have their phone attached to a special handle or a tripod. They cannot move their phone around. We should not lock their display to one specific orientation with the CSS rotate and/or transform property.

      One of the newest success criteria discusses authentication issues the users may have. Authentication should not strain short-term memory with puzzles, so we need to make sure that our login feature allows for copy-paste and/or the use of a password manager. Make sure your input fields provide proper "label", "type" and "autocomplete" html attributes. Apart from that, we should no longer require the users to solve the CAPTCHa in which the content needs to be deciphered and then typed into an input field. Object recognition is still allowed at AA level, but if you wish to succeed with AAA, even this type of CAPTCHa should be removed."

      How to set Pipi configuration

      Mike's Notes

      Here are my notes from today's work on the Website Engine (wbs).

      Resources

      References

      • Reference

      Repository

      • Home > Ajabbi Research > Library >
      • Home > Handbook > 

      Last Updated

      17/05/2025

      How to set Pipi configuration

      By: Mike Peters
      02/02/2025

      Mike is the inventor and architect of Pipi and the founder of Ajabbi.

      I'm manually migrating my first customer's website to Pipi's hosting. This is an excellent product test of the Website Engine (wbs), which sets up website hosting.

      The next problem is enabling simple bullet-proof configurations for future customers to set up websites using no-code.

      Each of the hundreds of modules will have many configuration options in the future, so a standardised system-wide process is needed.

      This morning, I sketched some ideas on how the Admin User Interface (UI) might look.

      This afternoon, I figured out that the Namespace Engine (nsp) already has a way to register the interfaces of every engine that is automatically built by the Factory Engine (fac).

      I added another Interface Class Type, "Config", and solved the problem.

      This allowed the fast addition of these examples of global properties that a website might have as options for the admin.

      • Meta Title
      • Meta Keywords
      • Meta Description
      • Domain Name
      • Default Language, e.g. eng
      • Plugins
      • Default Theme
      • Use References
      • Use See Also
      • Use Keywords
      • etc

      Doing this also automatically generates config variable names used in internal messaging.

      This would also enable configuration storage in XML or other open formats for interchange purposes and documentation.

      This configuration system will also work for all the other engines and could be used for open-source SaaS applications.

      If you want to become good at system design, then learn these case studies

      Mike's Notes

      I get Neo Kim's regular system design newsletter. It explains how large, popular systems scale in production by examining their design. Many of the solutions are elegant. This is an excellent newsletter.

      Below is a recent note from Neo with links to popular articles. I reformatted the links so they look better on my blog.

      The article on URL shortening is my favourite.

      Resources

      References

      • Reference

      Repository

      • Home > Ajabbi Research > Library >
      • Home > Handbook > 

      Last Updated

      17/05/2025

        If you want to become good at system design, then learn these case studies

        By: Neo Kim
        The System Design Newsletter: 24/01/2025

        What would you add to this list?

        PS - Join 100,000 and get the powerful system design template (it's free): newsletter.systemdesign…

        If you liked this note, restack & help others find it