5 minute read


We’re fascinated by building quality in - as opposed to glue it on after the release. We continuously improve the eco-system that surrounds software development.

👈 Click to expand slide deck
Software is eating the world DevOps Is Gulped Lakruzz' law Contemporary DevOps buzzes
Slide deck

Anything as Code

We believe in anything as code.

If “whatever you’re trying to achieve” can be solved by a snippet of software, then your solution is software. It’s code! And we know how to deal with code:

When code is done right:

  • It’s programmable
  • It’s immutable
  • It’s semantically version controlled
  • It’s automatically tested
  • It’s documented
  • It’s componentized and dependencies are managed
  • It’s released as packages
  • It’s maintained

Alright, this may not sound like a big deal. But it is!. Although most professional software developers know this and would love to work like this. The everyday life of a software developer is filled up with tedious manual processes, wait states, hand-overs. All the kind of things that er generally considered waste in an non-optimized value stream.

“We’re making software, that software developers use, when they make software.”


When Toyota faced the problem of building quality cars with small means, with scarcity of basically all resources, including funding, and entering into a playing field where the competition at that time was 1000s times better prepared than themselves, they took an entirely new approach that has inspired the world - and especially the software industry - ever since; The Toyota Production System (TPS) or lean as it was named when used outside Toyota’s own sphere.

They were the ones who came up with the ideal to build quality in - as opposed to glue quality on. The Japanese word is “jidoka”. And some of the core principles they applied to achieved this was “kaizen” - Continuous Improvement and “kanban” - Signaling.

In Continuous Delivery, DevOps and Automated testing we’re especially inspired by Toyota’s one-piece-flow. Toyota built an assembly-line that was deliberately designed to make problems surface immediately. They would not build individual components for stock - and then later assemble them. Instead they would organize the assembly line so that in the start there was nothing - and in the end there was a finished Toyota, ready to be shipped of to the customer. At the time, this approach was definitely not considered the most efficient way to build cars - but is should proof that it was definitely the most effective (the subtle distinction between efficient and effective is deliberate).

It had a huge effect! A lot of problems surfaced. All the time. In fact so many, that in the beginning they had a hard time delivering cars at all. Most of the time the factory was at a stand-still; fixing problems in the one-piece-flow through means of kaizen - continuous improvement and reorganizing the tasks to adhere to the concept of kanban - signalling.

The story of The Toyota Way has many more nuances than described in the three paragraphs above - But for now it’s sufficient to make our point; that a holistic view based on system thinking and problem solving is also at the core of how we work. And The Toyota Way is definitely worth diving deep into.

Software Development Lifecycle Management - complex by nature

The field we’re entering can be referred to as Software Development Life Cycle (SDLC) management or by terms such as Continuous Delivery and DevOps but no matter by what term we name it, it’s build on the same one-piece-flow mindset as Toyota introduced. In realty though; this is very complex - by nature probably even more complex than building a car, due to the inherently intangible nature of software.

In The Tech Collective we’re crazy about building and continuously improve this eco-system. This eco-system around code is essentially what we help and assist our customers in establishing. We make sure that the characteristics we define for code-done-right apply. We construct one-piece-flows and hereby guarantee that problems surface early, then we solve them - continuously, and eventually we build quality in - Jidoka.

Software Is Eating the World

Famous quote by Marc Andreessen, Wall Street Journal, 2011, meant to encourage venture capitalist to invest in software companies; "Software companies are not just a bypassing trend, they are actually here to stay". Today we know, that not only is software a good investment, it’s literally eating the world.

Even software is being gulped and swallowed by software. Concepts like "DevOps" and "Agile" are now implemented and supported in platforms, tools and utilities. The time has passed where we need to discuss the concepts, now is the time to embrace and utilize the tools and technology. It’s a new world.

Most companies do not have the the tech savvyness required to embrace the emerging tool-stacks. They stay where they are. But the problem with that approach is that while it may seem to seem to offer stability, it’s actually doing the opposite. Software is inherently complex by nature and the software monster should be fought with - more software. All the competitors on newer tool-stacks will outperform you - eventually. While software is eating the world.

If "DevOps" is an old - soon to be obsolete - term (it’s definitely bloated; what does it even mean?). Then what are some more contemporary buzzes? What are the weapons we can take to battle to fight the complexity of the software monster - eating the entire world - software included?

  • Developer Experience
    (DX)Improving the productivity, satisfaction, and collaboration of software developers
  • Internal Development Platform (IDP)
    Providing a self-service platform for developers to access resources, tools, and environments
  • Platform Engineering (PE)
    Designing and building scalable platforms for software development and delivery
  • Social coding
    Sharing and collaboration on code using platforms like GitHub and GitLab
  • FlowTech
    Applying lean principles and practices to optimize flow of value from idea to utilization
  • Infrastructure as Code (IaaC)
    Managing and provisioning infrastructure using version controlled code and configuration files
  • Declarative Pipelines
    Specifying the stages and steps of a software delivery pipeline using a declarative language (often YAML)
  • Serverless
    Running code based exclusively on cloud services, cloud functions, and APIs, without explicitly managing any infrastructure
  • Automation
    Reducing manual tasks and human errors by using scripts, tools, and workflows
  • Containerization
    Using light-weight containers and cluster orchestration over physical or virtual machines – servers aren’t pets or cattle, they are mayflies

Reach out - touch faith

Personal Jesus A common prediction these days is that more and more software in the future will be done by chats and generative AI, but the eco-system that surrounds software - generative AI included, is so carefully adapted the individual team, organizations, tool stack and domain knowledge, that this is not merely distilled wisdom of the crowd which is the force og Generative AI. The eco-system that surrounds software calls for sophisticated thinking and rehearsed problem solving skills. “Reach out, touch faith” is the chorus line in Depeche Mode’s legendary hit “Personal Jesus” - We offer you a chance to reach out and touch faith; Call us if you need help or join our free events and well get a chance to talk.

If software is truly eating the world - you job should be to tame the software.

Lars Kruse