Technical debt is a techie problem, the business should not pay for it. If you have some technical debt, it’s because you hired some bad staff. The good ones get everything right.

I have heard this way too often from both CEO and COO who do not really get it. And that’s because technical debt is not a technical problem, yet by calling it technical, we create a barrier to understanding that it is a business problem. Let’s look at a tiny aspect of it, that of security…

Of course, no one seems to want to improve their security nowadays: ship fast, break things, and let the next person worry about it, right?

One person who does care is the hacker. They are going to make thousands from you as you lose millions in the process. Or worse, they’re just going to get kudos from their l337 h4ck3r¹ friends.

The Security Debt Problem

Applications continue to ship with known weaknesses even as development workflows speed up. A new Datadog State of DevSecOps 2026 report examines how dependency management and pipeline practices are influencing exposure across cloud native environments.

Across the environments studied, 87% of organizations run at least one exploitable vulnerability in production services, affecting 40% of those services. This condition points to a persistent accumulation of security debt inside deployed software stacks. Your dependencies are 278 days out of date and your pipelines aren’t protected.

What happens next? You get hacked. Your customer data is stolen and leaked on the dark web. Your customers curse you and leave in droves. Your name is in the news as the weekly company that treated security as an after thought. And everyone laughs behind your back.

How do you fix it?

We know it is possible as is shown here: UK reduces cyberattack fix times from two months to eight days. But, how?

First, patching is critical. You need to have a rolling update of all your dependencies. It costs resources and is not glamorous but it is needed. How it works is simple:

• Week 1: Patch all dependencies in development and fix all the new issues it causes.
• Week 2: The patches get into the testing environment and are explicitly tested.
• Week 3: The patches get into the staging environment and are monitored for failures.
• Week 4: The patches are deployed into production.

If you really want to be efficient, this means that every week your developers patch their dependencies.

Second, there are plenty of open sourced and free security scanners. There are, of course, many pay for tools as well — for example…. Running one of these in your CI/CD pipeline is a sure way to find out which need to be updated as a priority. Of course, this is only as good as those tools are good. Still, having multiple ones is not hard to set up and is a good way to catch those elusive vulnerabilities. One problem here is that of false positives: you must review it all which can lead to alert fatigue.

Finally, and most importantly, as technical leadership we need to make sure that the business at large understands that this is not a cost. It is protecting your revenue stream. It is the equivalent of locking your car and taking the keys with you, not leaving the key in the ignition in the car park. You need to set resources (technical, monetary, and time) to protect your revenue stream. How much is often dictated by your company’s risk appetite: How much would a breach cost you?

Conclusion

This is just a tiny aspect of the problem. It is an opportunity to change minds, to educate senior leadership who, for entirely understandable reasons, do not understand this aspect. This is what I have done many time in the past, and I can do again for you.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

How about getting in touch to see how we can help you?

A CTO might be tempted to cut costs, save resources, and increase speed of delivery by cutting the test environment. It’s yet another bureaucratic layer in the way of delivering software that will make the company even more profitable.

A CEO might put the same pressures on their CTO, adding that they are confident they hired the best of the best who use the latest AI and SDLC best practices. After all, they are paying these staff so much.

Why waste time?

Why waste money?

Why delay yet again a release that is already late?

Why indeed… Read on.

Why should your CEO care?

“That’s nice. What is a test environment for?” — Your CEO, maybe?

While these arguments may seem compelling in the short term, the long-term risks of not having a test environment often outweigh the benefits.

First, a single major production outage or security breach can cause reputational damage, financial loss, and customer churn. How much does it cost for your service to be down for half a day, or a few days? Do your SLA ensure that you have 99% online time? Once is fine, twice is negligence and customers will move away.

Second, who do you want to find bugs in your product? Your paying customers? Would they be thrilled by this? Are you thrilled when you have to report a bug to a vendor you use? Or would it be better if those issues are found before the customers even see them? Even if that bug is simple as a spelling mistake or a link leading to a 404 page. Some potential customers might just use this as an excuse to go to your competitors.

Finally, the confidence that your latest features are deployable in a timely fashion gives the sales and marketing team confidence that when they say something will be available, it will be. Predictability is a major selling point.

Investing in a test environment is a strategic move to ensure reliability, security, and customer satisfaction. Or, as we are keen on saying, become drama free.

What Makes a Good Test Environment?

As far back as 2013, DevOps research from Gartner identified live-like test environments as one of the main factors correlated with high software velocity (the other was feature switches). Gartner has not changed its mind in 2024 stating that well-defined test environments are a prerequisite to delivering high-quality software using agile and DevOps practices.

Many things have to go right to have a good test environment.

It has to have environment Parity with Production: your test environment should be a clone of production. This means the same database, same configuration, and same pods/containers. The scale might much smaller (after all, there’s not going to be 100s of thousands people using it at the same time), but it should have the same things as productions.

It has to be isolated and independent. It should be on a different name space (do not share TLS certificates!), but run on the same base metal. If something catastrophic happens there, it should not affect production or development or anything else. And something catastrophic will happen there! It is where you can see what happens when it does so you can fix it before it hits production.

Because it will break in unexpected (and sometimes expected) ways, it should have automated provisioning and teardown. Infrastructure as code is a great concept that is perfect for this. This is especially true when you have to create the same environment on different providers.

Realistic test data is essentials. This is probably the hardest thing to get right. Testing with realistic, anonymised, or synthetic data that mimics production data ensures accurate validation of features, performance, and edge cases. Yet such data is hard to make. Thankfully, this is a place where generative AI can do wonders for you. This is the only place where hallucinations are a good thing.

Even more than comprehensive monitoring and logging. There should be an excessive amount of data there. Run all the code in debug mode (or at least the new features), with full audit logs. When things go wrong, you want to have as much information as you possible can. Of course, it means that you can drown in a sea of data, but we have AI for that…

However, all these things are utterly irrelevant if you cannot get funding. This is where you should re-read the previous section: why should your CEO care that you have a test environment?

Continuous Delivery where Test is Production

In the last few years, a lot of companies have been going the continuous deployment (CD) route where deployment to production happen many times per day. DORA 2024 has data that correlate CD to highly performant software¹. For this to happen, one needs a automated efficient, robust, and complete continuous integration (CI/CD) pipeline.

Netflix even went further and runs chaos monkeys which will randomly terminate virtual machine instances and containers that run inside of your production environment. Exposing engineers to failures more frequently incentivises them to build resilient services. Understand that such monkeys are the final step in a long road.

However, CI/CD is not suitable for releases. Enclave software has its own patching cycles determined by the client, not the vendor. And in some cases, even those get tested by the client before being accepted: Anything safety critical in hospitals, the military, and aerospace is unlikely to accept multiple releases per day.

Conclusion

As a CEO, we hope that you now have a better idea why test environments are so important. And as as CTO, we hope you have the reasoning to get the budget to get one setup. There are lots of details that we glossed over. But this is a start. Sometimes, you have to slow down to go faster.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

How about getting in touch to see how we can help you?

Key Performance Indicators (KPIs) have been used by businesses to measure whether an organisation, team, or employee is meeting a predefined goal. It is related to, but different from, metrics which display the performance of tasks, processes, or activities. To be effective, KPI should also follow the SMART (Specific, Measurable, Achievable, Relevant and Time-bound) framework to ensure that goals are realistic and can be met. For more information see KPI basics and KPI definition and examples

Peter Drucker

If you can’t measure it, you can’t manage it.

Peter Drucker, often heralded as “the man who invented management”, stated that you need to quantify and observe something in order to understand and improve it [source].

This is something at the core of the SRE/DevOps paradigm: if it moves, graph it. It is something that any developer knows when looking at optimising their code. First, measure. Second, try something. Finally, compare the before and after.

KPIs have been used to look at individuals, teams, and organisations to look for quantifiable measures of progress towards a desired result. The desired result is generally set by leadership to improve some aspect of the business. A good set of KPIs will help steer the organisation to the right direction. It takes the guess work out of the process. It gives a clear direction to those teams and individuals as to what matters most.

This can only be a good thing, right?

Right?

…

Goodhart’s law

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

Charles Goodhart stated this in 1975. Of course, Goodhart’s law [source] is not the first time this has been said and is a perfect example of a law of unintended consequences.

Humans, as a species, are extremely adaptative at gaming any system. This is why we do so well as a species. If we are under some pressure to do a thing to get a reward, we will ensure that we do all that can be done in the most effective way to ensure we meet those targets. An example of this are murder closing rates in the Police: it is quicker to pin the murder on the first person that fits than actually investigate them.

In the software world, a company which shall remain nameless instituted the following KPI: For developers, bug fixes per week. For SQA staff, bugs found per week. It was amazing! There were many bugs found and fixed. Management was happy and everyone got a bonus for smashing the targets! That is until the day where a list of bugs created by the developers was intercepted before it reached the SQA team… Simple: developer write a bug, tells SQA where to find it, and both get rewarded from the KPI.

When a measure becomes a target, it ceases to be a good measure.

So, are KPIs worthless after all?

Harmony or Discord?

When a measure becomes a target, it ceases to be a good measure.

It depends. A good KPI can be a great measure of progress, but it can also be obfuscating what is actually happening. A KPI needs to follow the SMART framework to ensure it has a chance of falling into the former category. It is a tool that, as a hammer, can be used to great effect. If used wrong, then it can be a tool for discord.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

How about getting in touch to see how we can help you?

Everyone is talking about AI this and AI that, but what are artificial intelligences? Are they the Neuromancer and Wintermute of Cyberpunk¹ or precursors to the ships minds of the Culture?²

No. Generative AI refers to deep-learning large language models (LLM) that can generate text, images, and other content based on the data they were trained on. MIT has a more detailed explanation.

And it is worth remembering that the “I” in LLM stands for Intelligence. LLMs are not aware of context and cannot reason. All they do is generate content based on the data they were trained on.

For simplicity, when we talk about AI herein, we talk about generative AI, or LLM models. The terms are interchangeable.

Policy

Do you let your staff use AI? If so, do you have an AI policy or are they free to do as they wish?

Trump’s acting cyber chief uploaded sensitive files into a public version of ChatGPT and Gartner Predicts 40% of AI Data Breaches Will Arise from Cross-Border GenAI Misuse by 2027 The risk of your confidential data being leaked, not even maliciously, are as simple as a copy-and-paste.

An AI policy, like the template one provided here offer you a good starting point for your staff to follow. It should outline which tools are allowed, what data is shared, and how it is used. Training of your staff is essential here.

While meant to be funny, you could do worse than using these tips for using AI…

Hallucination

Are you, and your staff aware of AI hallucinations? Can you explain what they are?

The term draws from psychology where a patient see or hears something that is not there. It is a response generated by AI that contains false or misleading information presented as fact. The rate is hard to measure since there are many factors that go into it. However, it is generally assumed that any AI will hallucinate around 15% of its output. Therefore, it is essential to never trust the output of an AI without reviewing it yourself.

Why do AI hallucinate? offers a good review of the topic from OpenAI.

Security

Did you ever have to secure an AI system? If so, how did you do it?

Why AI systems may never be secure, and what to do about it and How to stop AI’s “lethal trifecta” from The Economist talk about some of the problems that are facing AI systems. To answer those, both the UK’s Cyber security risks to artificial intelligence and the NIST AI Risk Management Framework were created.

One thing is certain, unless you fully control the model, you cannot be secure. Relying on a subscription for it might offer some degree of protection, but you will be at the mercy of the providers’ security. Therefore, make sure you ask them for their SOC-2 or ISO 27,001 reports. If they don’t have those, maybe the risk is too high to use them?

How much do you trust your vendors?

Adoption

Did you have the conversation of adding AI to your product, or using AI to help you build your product?

Of course you have. Everyone is doing it from Microsoft to DuoLingo, everyone is adding AI everywhere regardless of whether people want it or if it makes sense. Billions are spent on data centres, RAM, and GPU to power those, but where is the demand?

The search engine DuckDuckGo asked users how they feel about AI search and 90% said they did not want it. A recent CEO survey states that half of the 4,454 CEO respondents said “their companies aren’t yet seeing a financial return from investments in AI.”

Taking a step back might be a good idea here. Look at where it makes sense to use AI and where it makes sense to have AI in your product. Just adding it so you have it is not going to increase your revenue.

AI Generated Code and Vibe Coding

Did you ever wondering if a programmer could be replaced by AI? Do you know Vibe Coding? Have you done it yourself? Were you impressed or did the AI destroy your production database?

Yes, this can happen. ‘I destroyed months of your work in seconds’ says AI coding tool after deleting a dev’s entire database during a code freeze: ‘I panicked instead of thinking’

Last year, we had our post on the good, the bad, and the ugly of AI code which is still very much relevant today. However, we now have more data. We are starting to see some results from vibe coding. For example, the state of AI vs human code generation report gives us some data:

• 1.7 times more issues in AI generated code
• 1.3 to 1.7 more critical and major findings
• 75% higher prevalence of logic and correctness issues

In addition, the report highlights the following:

Internal dashboards show more late-stage defects, SRE teams report more operational incidents tied to logic and configuration errors, and several high-profile postmortems in 2025 have pointed to AI-authored or AI-assisted changes as contributing factors.

Do you think an AI can use SOLID or KISS, or other best practices?

Remember, the I in LLM stands for Intelligence. The LLM has no context, no reasoning, no way to apply any of the above best practices to the code they create. Even worse, small changes in the prompt can create varied results, some more maintainable than others. It is fire and forget code. Which can be very valuable or not, depending on your use case.

In DORA 2024 the data showed that 75% of developers reported higher productivity with AI. However, delivery was down by 2% and stability was down by 7% — Not a good outcome! DORA 2025 (see below) states that the best results of AI adoption in software development is that of an amplifier. The whole report is really worth a read — grab it and a coffee, you won’t regret it!

All this points to a need to have a good understanding of the factors that affect the development processes and how AI can enhance those. It is not a plug-and-play interface just yet.

Conclusion

All of these questions, and more, are under our foundation of AI.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

The only way to proceed is to have a company-wide AI policy, pick the right AI tools to use, and keep to the best security practices for secure code development. AI is a powerful tool, but the benefits of its use may be outweighed by the pitfalls of its misuse. The way your business engages with AI is a critical factor, whether your technology team become advocates for AI software code generation or develop an adversarial relationship to it. With our understanding of the abstract factors, we can create the right approach for you.

This is part of a series on all our foundations. Here are links to the next entries:

People
Development
Security
Operations
AI

To understand this, you must first think - what do the users of our services expect?

They expect the service to be there when they show up. If it’s not there, they expect that you already know, and you are working on it.

They expect features to appear regularly, and for those rollouts not to interrupt their usage (much). They expect bugs to get fixed in a reasonable time.

They expect things to work as expected, or at least as described. They expect some help. They expect their data to be secure. They expect you to tell them if that’s not true.

All this tells us that drama is bad, failures should be minimised, and predictability is king.

Achieving reliability, velocity and clarity

These things are choices, management choices, because they all cost money to achieve, and you will get as much of each as you pay for. But none of these things are just for sale. There’s no service called AWS Reliability Server. You have to design your development processes to achieve them.

Reliability is a choice. You decide how much time you put in to flexible designs and then painstaking testing to achieve reliability. You’ll need a good test rig. Do you have one? You’ll need to spend time chasing down small, persistent bugs. Do you give your devs time for that?

Reliability needs a deep understanding of what your systems are doing. That means observability - instrumented code, dedicated effort to expose both technical and business metrics, both in live and in test environments. It needs good load simulators, that exercises many code paths and at scale.

Velocity is not gained by thrashing your devs to work longer hours and focus on features. That might get you through a single crunch, but the tech debt piling up will bleed your velocity before long. Do you have good, live-like test environments with good, live-like data in them? Hint, the second part is actually harder and you may need to pass this as a requirement into your data design.

Velocity comes from finding bugs at the first possible opportunity, which means testing and CI/CD. It comes from limiting tech debt by just spending some time burning down the worst of it. It means decent documentation, because new developers will always need it.

Clarity is taking time to do the secondary things for your users. Do you write good user docs? Do you do videos showing how to do things? Do you get a UI specialist to figure out workflows and design the controls?

Clarity comes from the right thing to do being the easiest thing to do. It comes from contexturalised help. It comes from clean design.

Behind the scenes in the Fantastic Website Corporation

A service that users love, rely on and build into their life is never that way by accident. You cannot leave release, support, problem management or testing to chance. Hope is not a strategy.

As a company moves from a small startup where yes, anything goes, up to a larger enterprise, the changes are not because The Money Men demanded enterpriseyness. The change are because you need to be seen as dependable by your customers, or you won’t stay large.

All the effort on change management, incident control, release engineering, monitoring and alerting that big organisations engage in is not just stodgy ITIL thinking, it’s because these are the secondary activities that underpin good operations.

As a small company, you got where you are going because you move fast, right? Well, the Wile. E. Coyote stuff might be OK when you have 7 customers, but half a million customers will expect you not to run face-first into a painting of a tunnel. Even if the Shiny New Website Company somehow went through it.

So do you know what you need to do to improve release to the point where you are not scared of a rollback? How about data migrations? How about customer-side code?

Do you know what observability is realistically enough? And how do you get it with 3rd-party software?

How do you design data models for good live-like test environments?

All of these questions, and more, are under our foundation of operations.

Drama belongs on TV

If your code release are dramatic, they are under-engineered. If change management is dramatic, it’s probably not got all the right people doing all the right things. If incidents are dramatic, you… well, OK, some big incidents are dramatic, but small ones should be simple and easily learned from.

With our understanding of the abstract factors, we can create the right approach for you.

This is part of a series on all our foundations. Here are links to the next entries:

People
Development
Security
Operations
AI

Have you, or someone you know, been scammed? Ever got a phishing or a 419 email or a dubious link which turns out to be Rick Ashley’s most famous song?

This is likely to be your first encounter with cybersecurity, when it is too late. But, what do cybersecurity staff actually do?

At its core, cybersecurity is about the Confidentiality, Integrity, and Availability of data — Hence the CIA acronym. In addition, there’s the incident management, from prevention and mitigation, to response and recovery. It aims to keep your data safe, and your business secure.

CIA

When we speak of data, we mean both documents, information, and the systems that host them.

How do you defined CIA?

Confidentiality is about keeping your data consistent, accurate, and trustworthy over its entire lifecycle. The data must be protected against access by unauthorised users. It is encryption, firewalls, and access control lists.

Integrity is how you make sure that your data is what you say it is. The data must be protected against alteration and modifications by unauthorised users. It must be audited for authorised alterations and modification. It is data quality, backups, data validation, and disaster recovery.

Availability is about making sure that the right people have access to the right data. It is passwords, two-factor authentication, and IAM roles in the cloud. Together with confidentiality, it forms the basis for authentication and authorisation.

Confused about the difference between authentication and authorisation? You’re not alone.

Authentication is who you are, authorisation is what you are allowed to do. Here is a metaphor on the difference between authentication and authorisation: At the airport, authentication is your passport and authorisation is your boarding pass. You cannot get to the gates without the former and onto a plane without the latter.

How do you know what to protect and by how much? Is a million too much money to spend? Not enough? As an executive, how do you know what to do?

It is all about risk acceptance. What risks are you willing to accept versus how much resources you are will to pay to mitigate them. There are no easy answers here. A risk register is a good starting point.

How does this apply to software? Do you need to worry about it, or can we paint over it later?

Insecure software can leak user data which can lead to fines. Your users might choose a different service because their data was leaked. New users might read that your software security is poor and go with another vendor. The cost to the USA economy of bad software was a staggering $2.08 trillions in 2023. The earlier cybersecurity is implemented, the more secure your software is: cybersecurity is dye, not paint.

What about software we use, but do not control?

This is supply china security. Things that your software depends on, libraries, modules, and the whole ecosystem behind it. From cyrpto-highjacking, to social and political activism, to just discovered vulnerabilities, your software is vulnerable to vulnerabilities in dependencies of dependencies of dependencies. EU revised Cybersecurity Act has plenty to say about just this. Software Bill of Materials, or SBOM are getting more and more popular to tackle this issue.

Incidents

Ever heard your CISO say “We have been breached”? Do you remember the cold sweat and panic that sets in? What was the last time you saw a security incident? How was it handled?

Let’s cast our mind back to 1967 when the USS Forrestal was off the coast of North Viet Nam. During the punishing operations, a MK-23 Zuni rocket misfired causing a catastrophic chain of events resulting in a massive fire. After 14 hours, all the fires were finally controlled. The incident left 134 men dead, 161 more injured, and more than $680 millions (in today’s money) of damage as well as impeding military operations in North Viet Nam.

Why was it so bad? The US navy after action report highlighted poor and outdated doctrine, technical documentation, and procedures, at all levels of command. To remedy this, the Navy opened a firefighter school, the Farrier Firefighting School, where all future sailors are trained in fighting fires.

What has this got to do with cybersecurity, I hear you ask?

The old adage holds true: You fight how you train. If your staff has no knowledge of what do during an incident, they will panic and do the wrong things, thus making things worse.

When is the last time you ran a security incident training?

How did your staff do?

Humans and Adversary Relationships

Do you know Dave? The one in the cartoon below.

Yes? I think everyone does…

We, as a species, have done so well because we are fantastic at gaming any system we find. It’s how we tamed dogs, fire, and wheat, rice, and maize. It’s how we built the hanging gardens of Babylon and put men on the Moon. Any policy or tool blocking someone from doing their job will be circumvented in hours, if that. For example, the financial world did not have a good mobile communications platform, so everyone started using WhatsApp. It is not compliant and banks are being fined every year for using it. Still, they are using it.

People matter and cybersecurity should make it easier to do their job, not harder — in a secure way, of course. Sadly, some cybersecurity professionals are very much like the cat below. They say NO to anything new, anything that changes, and anything that is not what they know. Remember the A in CIA? That’s where those cybersecurity teams are failing.

Good cybersecurity is a dye, not a paint.

It permeates all the aspects of your company and makes sure that everyone can do their jobs more easily in a secure way. Cybersecurity should be everyone’s friend, not their enemy. From naming security champions, to actively listening to the pain of users, and tailored training, you can get all your teams to be more secure. In the long run, it will save you millions. 43% of UK business reported security breaches in 2025. Make sure you are not on these in 2026.

And remember: compliance (such as SOC-2 or ISO 27,001) flows from good cybersecurity, not the other way around.

Conclusion

All of these questions, and more, are under our foundation of security.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

We can help with implementing nascent cybersecurity such as Cyber Essentials, or NIST Cybersecurity framework, and compliance such as SOC-2, ISO 27,001, and the EU revised Cybersecurity Act. We can incorporate practical and sane cybersecurity early into the development process saving you future costs. With our understanding of the abstract factors, we can create the right approach for you.

This is part of a series on all our foundations. Here are links to the next entries:

People
Development
Security
Operations
AI

Good software is software that makes a profit, right? It’s the one that sets your company apart, that generates more revenue, and that makes your customers happy.

How does it come about?

Development is what happens when senior leadership has a vision what gets translated into a strategy which, in turns, gets implemented into a product that eventually sells. Sounds simple? It is, but the implementation is a complex hydra with many heads.

Does over budget and over time software sounds familiar? Does broken software cost you money, times, and resources to fix? Are your software releases stressful and frustrating?

If so, you’re not alone. Data shows that 80% of software projects are over time or budget and that for every $1 spent on software development, $.50 is added in bug fixes.

Ever had a software release pushed back? Even worse if it happened twice or thrice? All that marketing and sales money hanging in the balance and more spend on damage control?

Predictability is what all software methodologies aim to solve. Be it with story points in Scrum/Agile¹, the velocity of Kanban, or the fixed dates of Waterfall/V model, or the (mythical) man months estimates. And fundamentally, this is impossible to answer as development deals with many unknowns. Developers can predict what they know how to do, but not what they think they can do or what they don’t know how to do. Writing software is a complex matter, with many unknowns, some unknowable, from the start.

The Software Development Life Cycle — SDLC

The Software Development Life Cycle (SDLC) aims to make those unknowns more predictable. It aims to provide a clear framework for planning, building, and maintaining software, ensuring that development is systematic and meets quality standards. There are many implementations of the SDLC, all claiming to be the best. For some companies, they are. For others, not so much.

Agile has Scrum, Lean has Kanban, and mixed together make Scrumban. The popular (according to DORA) CI/CD model aims to release software multiple times a day. It does require robust automation testing for it to work. However, it is not well suited for all software. Your complex website is a perfect environment for CI/CD, whereas safety-critical software that runs a plane or a submarine is not.

Quality

Have you ever had software that didn’t quite do what you wanted? Or did it badly and awkwardly? Software that was full of bugs?

Quality assurance is always seen as a cost, not an opportunity to achieve the vision of robust software. From verification (what the product complies with its specification and requirements), to validation (what the product meets customers needs), your SQA staff are key in rising customer satisfaction and thus your revenue.

Developers build. Testers break. Together they complement each other in making a robust product.

You will pay the cost of fixing bugs in your software. The question is, will you pay it before or after customers see it?

Did you ever struggle to read the documentation of a piece of software? And how bad was this software?

DORA 2024 had a strong relation between good documentation and performant software. Which is no surprise: if you must write documentation, you must first understand your software well which in turn, reveals its weaknesses. One of the question we are fond of is: “That’s nice. What is it for?”

Shift Left

When was the last time you heard the developer manager say “it is done” and then DevOps retort “Err… No!”? Then Cybersecurity looks at it and starts crying?

Security is a dye, not a paint. The same thing holds true for operations. The sooner those concerns are addressed, the less painful they will be. From the OWASP Top 10 and 12 factor app, the shift left of operation (DevOps) and security (DevSecOps) has been gaining momentum and popularity. The reasons are many, but the main one is cost. It is much cheaper to fix something earlier than later.

Illustrations of DevOps (above) and DevSecOps (below), as part of the SDLC.

Business Debt

Also known as technical debt, this is the debt that is accumulated over time by those unknowns that developers cannot predict. Sometimes, it is debt created by deadline and the corner cutting necessary to meet a deadline. External factors, such as third party software (libraries, modules, frameworks, etc…) require more work than just updating to the latest version.

We call it business debt because the business pays for it. And the interest is brutal. It can easily make a new feature take months to make instead of weeks, if it’s even possible.

How do you cope with it? Is it an ever increasing mess? How much does it cost you?

Artificial Intelligence

Does it have AI in it? Who has not dreaded this question from customers or investors or friends?

It is impossible to avoid AI nowadays. Every company has added it to every product and since the last four years, we keep hearing that there will be no developers needed in six months. From the hype to reality, AI is still so new its impact is being just felt.

In DORA 2024 the data showed that 75% of developers reported higher productivity with AI. However, delivery was down by 2% and stability was down by 7% — Not a good outcome! DORA 2025 (see below) has three pieces of advice on AI adoption:

1. Have a system view to solve the right problem.
2. Invest in foundation systems.
3. Focus on effective use to guide, evaluate, and validate AI generated work.

We will have more on this is our last foundation post in three weeks.

Conclusion

All of these questions, and more, are under our foundation of development.

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

Transform your development teams, your software, and your product with us. Be it with Agile or Lean, get the right solution for your problems with measurable data leading you to a path of constant improvement. With our understanding of the abstract factors, we can create the right approach for you.

This is part of a series on all our foundations. Here are links to the next entries:

People
Development
Security
Operations
AI

People are the foundation of your business. However, it is not as simple as just saying it. Questions spring to mind, such as:

You see friction in the team, from personality clashes, to grumpiness, to “What fresh hell is this?”. Like a gear engine, it grinds painfully. But, how do you fix this? How do you get them all to work in harmony?

First, people in technology are overly neurodivergent, what works for one will not necessarily work for others and what motivates some, will not motivate others. Second, everyone has their own goals and expectations of how to get there. Finally, software production is a social process so good communications is essential.

You need to expand the team, but hiring takes 8-12 weeks on average and the cost keep rising from sifting dozen of AI generated CVs, dealing with recruiters, and the interview rounds. Then what? Do you really get the best people?

Everyone one wants the best of the best, but even if they hire for technical skill, disharmony can fester and kill the efficiency of the team. The flip side is that diverse teams are 50% more effective than homogeneous ones (Forbes), therefore hiring those with different skills and backgrounds is key.

Working together

How do you get everyone to work together in harmony? We all know the cartoon of the swing.

What is more shocking? That you have seen this in action or the publication date is March, 1973? Why are these communication problems still happening now?

As said before, programming is a social activity and communication is key in achieving your goals. The Agile manifesto is especially keen on this one. However, getting disparate people to work together can be a challenge especially if the goals are unclear. Communication does not have to be oral: writing good documentation is a sign of good software (DORA 2024).

Everyone has memories of drama associated with software: from bad specifications, to unrealistic timelines, via brittle code, and deployment catastrophes ending with working 12 hours days on weekend. All new (and old) software methodologies claim to help, but do they?

As Brooks said in his seminal work The Mythical Man-Month, there is no silver bullet. Scrum will be perfect for some teams and utterly destructive in others. Lean and Kanban work really well for some processes and get unwieldy for others. Nowadays, shift left is the buzz word merging operations and security with development: DevOps and DevSecOps. What will work for your company will be something unique.

Are the two problems above enough for your vision to be achieved? They do help and are necessary, but not sufficient. There’s always more…

Strategy

Google has pushed OKRs as way to get everyone to follow the same vision. There are other alternatives from BUPs (Bottom-Up Priorities) to SMART and the simplest are generally the best. The patterns are the same: measure the things you want to change, evaluate new things, and see how the metrics change. Now, enters Goodhart's law: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes”. Regardless of the method, the important bit to get your vision across.

All of these questions, and more, are under our foundation of people.

Conclusion

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

We have the experience to guide you through a transformation towards team structures that accelerates progress, give staff clear areas of responsibility, and ensures all aspects of the work are someone’s core task. Be that a well recognised Agile pattern or something more bespoke, our understanding of the abstract factors that we can create the right approach for you.

This is part of a series on all our foundations. Here are links to the next entries:

People
Development
Security
Operations
AI

The Impact of Poor Software Quality: A Data-Driven Perspective

First, according to Forbes’ “2025 Quality Transformation Report,” 40% of organizations say poor software quality costs them over $1 million annually. In the U.S., 45% of businesses report losses above $5 million a year.

Second, according to the state of software 2025 report, 60% have low security, 40% slow update rates when software architecture is poor (operations!), and a €7 million additional cost due to poor software quality in large systems.

Do we need a third point? … Probably not.

How is your software function really doing?

Assess Your Software’s True Health

Now you can know for sure by taking our software function MOT. It is a confidential (under NDA, either ours or yours) gap analysis or a health check if you wish, looking at all the things that go into making software more robust, performant, and secure.

This comprehensive health check delivers a 10+ page report, detailing your strengths, vulnerabilities, and most critically, a prioritized list of actionable recommendations to mitigate risk. Our approach is vendor neutral, ensuring independence, though we are available to provide deeper, tailored support through à la carte services or customized plans.

Proven Results, Tangible Value

We are confident that we can help.

We reduced extensive testing of giant underwater robots costs by 60% (thus saving several millions), reduced AWS bills by 40% (ongoing operational costs with added visibility and monitoring), and deployed AI to enhance medical workflow ethically. We even have case studies we can show you to prove those numbers.

Ready to de-risk your software’s future? Contact us to get started!

We have a new website.

Of course, I am sure we will get a flood of web developers telling us it’s wrong, ugly, and unoptimised. For a tiny fee of a few thousand dollars, they could do better. In addition to these, we’ll get SEO and, of course, some AI. No idea why, but we need it in the age of AI slop, right?

No.

Simple is good enough. The site is still based on Jekyll because we like things to be simple and fast. This time, the theme is a slight modification of the Feeling Responsive one. Hopefully, it gives the reader a clear idea of what problems we can solve for them.

What do you think? Feel free to get in touch and tell us.