Welcome to my corner of the web, where I share thoughts, insights, and lessons from my journey in software development.
Posts
No Plugin CI/CD Builds
TL;DR
Avoid over-reliance on CI/CD plugins that obscure processes and hinder local reproducibility. Instead, use scripts and Makefiles to automate builds, tests, and linting, ensuring consistency across local and CI environments. Plugins should complement, not replace, developer workflows—for tasks like environment provisioning, secrets management, or caching. Scripted automation simplifies switching CI tools and maintains fast feedback cycles, critical for developer productivity.
CI and plugins
A continuous integration pipeline that automatically lints, builds, and tests code changes is part of most if not all teams. There are many tools and products in this ecosystem to support and enable teams with managing their CI setup.
Don’t Be Too Rigid When Building CI/CD Platforms
TL;DR
The DORA 2024 report emphasizes how CI/CD platforms that automate test execution, reporting, and environment management help teams focus on writing high-quality tests. This is a major advantage, but there’s a slippery slope: overly prescriptive platforms risk reducing autonomy and engagement. Platforms like GitHub Actions strike a balance by offering reusable workflows with “escape hatches” for customization. By adopting simple contracts for test reporting (e.g., xUnit XML files), platforms can provide structure while preserving team flexibility, making it easier to integrate customized workflows into centralized analysis—thus combining the benefits of a golden path while avoiding ’lock-in’ into a prescriptive, rigid delivery pipeline.
What Is "Working Software", Anyways?
When discussing fast feedback loops and continuous delivery, the question often arises: What is the result of an iteration? What is the artefact that is continuously delivered? The common answer is “working software.”
This terminology comes from the Agile Manifesto, particularly the value of “working software over comprehensive documentation.” But what exactly does “working software” mean?
The Misconception
In many cases—often intentionally—it’s misunderstood as barely running software and nothing more. This interpretation is especially common in established industries like manufacturing or automotive, where it’s followed by arguments about why agile or continuous delivery “won’t work here” and how such approaches are actually reckless. It’s often judged as something suitable for low-risk contexts, like web development, but not for ‘serious’ projects.
On writing ALL tests first
A while ago, I had a conversation with a friend who shared how their team switched from a test after to a test first approach. They began with training and a workshop, using their actual codebase for real-life examples. My friend was pleased—they were now practicing Test Driven Development (TDD). So far, it sounds like a success story.
However, one detail bothered me: the method they adopted involved writing all the tests upfront. For experienced TDD practitioners accustomed to the red/green/refactor loop and writing one test at a time, this approach seems odd. I quickly learned that the “why” behind the TDD cycle isn’t always immediately clear or easy to comprehend. And that there are good arguments for an all tests first approach:
Low Code / No Code Platforms
I recently encountered the idea of Low Code/No Code Platforms in a client context and while my initial reaction has been kind of ‘No…please…No’, I became curious. Is my rejecting reaction just based on my bias as a software developer and code wrangler? Therefore I wanted to explore and understand this topic a bit better.
What are “Low Code Platforms”?
What do I consider low code application platforms (LCAP) in this context? Any kind of software development platform where the software is developed mostly using graphical tools. Not only for the UI but dragging and dropping the business logic onto some canvas instead of writing code in a programming language. Additionally, to support more complex scenarios, most platforms allow us to write some source code in a programming language. Often multiple deployment targets (e.g. mobile devices and HTML applications) or runtimes(e.g. JVM or .NET) are supported. Releasing into production often is just a mouse click away. Gartner predicts that until 2024 up to 65% of application development will make use of low code application platforms. Examples of LCAP are OutSystems, Mendix or Microsoft PowerApps.