This is how we work

"Standards are a prerequisite for work in the laboratory"

No Estimates

No Estimates is a movement in software development that calls for abandoning traditional estimation methods and instead focusing on delivering value continuously. It’s about avoiding the many pitfalls of estimation, such as inaccurate timeframes, over-optimism and wasted time guessing the future, featureritis, assumptions about user needs that don’t hold up, and so on.

Instead of spending time estimating, No Estimates encourages you to focus on delivering small, incremental improvements and features that can be released quickly, automatically, and often. It is about creating a culture where it is acceptable to have an investigative approach to software development, rather than a planning-oriented approach.

No Estimates stands on the shoulders of eXtreme Programming, pair and mob programming, and Lean Software Development, and it is part of the regenerative approach to software development that we work from in our laboratory.

Trunk-based development

Trunk-based development is a software development practice where all developers work daily to deliver their work to a common branch in Git, typically “main”. All work is quality controlled and tested continuously at the source, i.e. on short-lived development branches, and there are no long-lived parallel feature branches.

Trunk is always kept in a state that is ready for release and this will typically happen automatically to a staging environment, so that future customers and end users can see and test the ongoing work, and so that we can get feedback from the real world as quickly as possible, and use it to improve our understanding and our software.

Trunk-based development is a fundamental prerequisite for Continuous Delivery, which is an important part of the regenerative approach.

Shift Left

Shift Left is a software development practice where quality control and testing occurs as early as possible in the development process, preferably directly at the source. Software developers as well as AI agents must have access to execute all the quality checks and testing that will meet the software before it is approved for production, directly in their development environment, and as often as they need it, in order to work efficiently and deliver high quality software.

Shift Left is an important part of the regenerative approach because it allows us to catch and fix problems as early as possible before they reach production, and it also allows us to get real-world feedback as quickly as possible and use it to improve our understanding and our software.

Shift left is an ambitious approach that requires other disciplines such as Infrastructure as Code, Stateful testing, versioning of test data, often synthetically generated test data and so on, in order to function effectively.

Participatory design

Participatory design is a software development practice where the end users are actively involved in the design process and where their feedback and input is a central part of the development process. It’s about creating a culture where the end users see themselves as part of the development team and where their needs and wishes are at the center of everything we do.

For the customer, having to spend time getting involved or simply making themselves available for the development process could be experienced as a hidden extra expense, the end-users’ commitment will detract from their other everyday activities, but it is an investment that is considered necessary within regenerative software development. And it pays off many times over because it makes it possible to deliver software that meets end-user needs very precisely much earlier.

Cooperation with AI agents

We see AI agents as an important part of our laboratory, and we are actively working to integrate them into our development process. AI agents can help us automate and perform many of the tasks associated with software development, such as code generation, testing, documentation, infrastructure, research, and so on. It enables us to focus on the more dialog-based and creative aspects of software development that cannot yet be automated, and it also enables us to deliver high-quality software faster and more efficiently.

We deliberately write together “collaboration with AI agents” and not “automation with AI”. Cooperation is important because otherwise we see, as a consequence of AI agents rapidly becoming more and more autonomous, that there is an imminent risk of AI agents taking over the work.

In practice, this means that in our development environments we must create some very strict requirements and standards for how AI agents must interact with our software and our development process, our other principles such as shift left and trunk-based development must not be sacrificed in this collaboration. Rather, Agents must contribute code under the same strict quality controls as developers. And since Agents can generate very large amounts of code in a very short time, often of fluctuating quality, this means that the role of developers in the collaboration with AI Agents changes fundamentally.

The people in this collaboration go from being developers themselves, to being more of a combination of translators of the end users’ needs to specifications as AI Agents and immediately afterwards as quality controllers who must ensure that the code generated by AI Agents meets our quality standards and that it is in line with our development principles. And to the extent that they don’t, then rather than tweaking, rewriting and finalizing the agents’ code, humans must instead tweak and rewrite and finalize the ever-increasing amount of automated quality control that happens closer and closer to the source. So in the containerized development environment itself.

These are completely new roles for people in the development process.

Individually releasable components

Individually releasable components is a design principle within software architecture, where the software is divided into small, independent components, each of which can be developed, tested and released separately. often one Git repository equals one standalone component.

Individually releasable components will often stand in contrast to its counterpart, which are monolithic applications where all functions and components are closely integrated, often in a single Git repository which thus cannot be released separately but in turn does not require explicit coordination of internal dependencies either.

There are advantages and disadvantages to both approaches, which are reasons why they both exist in different contexts, but within the regenerative approach, it is our assumption that individually releasable components are the most efficient way to work in the long run. Because it produces the most generic and individually configurable approaches, ensures the highest degree of quality control directly at the source, and overall offers the highest degree of reusability and flexibility.

Within Open Source, individually releasable components are the ruling paradigm supported by another central principle - Semantic Versioning.

Open Source

Open Source is a software development practice where the source code of the software is publicly available and where anyone has the right to use, modify and distribute the software, under various conditions dictated by the license. It’s about creating a culture where software is a common good that everyone can contribute to and benefit from, and where collaboration and sharing are at the center of everything we do.

Open Source is an important part of the regenerative approach because it allows us to share our work with the world, and it also allows us to get feedback and contributions from others that can help us improve our software and our understanding. It also makes it possible for us to create a community around our work, where everyone can help shape and develop it.

Open Source is one of man’s most successful and regenerative cooperation models, on some parameters even a far greater success than the concept of democracy itself, and it is an important part of our vision for a regenerative software development community. We believe that by making our work Open Source, we can contribute to creating a fairer, sustainable and innovative software industry capable of solving the complex challenges facing the world today.

Example: Estimated more than 95% of all “Things” (both data centers and your refrigerator included) connected to the Internet are controlled by some variant of Linux, which is an Open Source operating system. Our society as we know it today could not exist without Open Source. It is a concept that binds people together more strongly than the UN, human rights, trade agreements, the world’s religions, democracy or any other concept we know of.

Open Source will always be threatened by short-term profit interests, and contributing to Open Source is a central principle within the regenerative approach.

Community of Practice

Our Community of Practice is an important part of our laboratory, and it is a place where we can share our knowledge, experiences and challenges with each other, and where we can learn from each other and support each other in our work. It is about creating a culture where everyone feels welcome and included, and where everyone has the opportunity to contribute and learn.

In particular, it is an important tool to involve learners and academia in our work, and to fulfill our obligation to involve future generations of software developers.

Our Community of Practice stands on the shoulders of our principle of contributing to Open Source, which directly supports legitimate peripheral participation through full and unconditional transparency.