When software fails, the cause often lies less in the code than in the contract. The decisive factor is whether success or effort is owed: If agile projects are effectively designed as a contract for work, the entire backlog can suddenly be deemed to be owed. Clear service descriptions, comprehensible quality criteria and a shared definition of the state of the art reduce liability, warranty and disputes. It makes sense to look at relevant metrics such as the expected residual error rate instead of mere coverage.
In this episode, I talk to Sebastian Dietrich about legal pitfalls in software projects. He is a court expert and shows why freelancers not only owe commitment, but success. Bugs, warranty, liability, duty to warn. Everything carries weight. It gets tricky for companies when agile contracts are considered contracts for work and services and the entire backlog is suddenly owed. We discuss how to describe services clearly, define technical quality and establish the state of the art as a common process. Instead of coverage fetish, we look at the residual error rate.
"Unlike an employee, a self-employed person owes a success and not just an effort." - Sebastian Dietrich
Since 2003, Sebastian Dietrich has been working as an expert for software quality and software maintenance in addition to his activities as a trainer, consultant and software architect. He has been a sworn and court-certified expert since 2015. In this role, he ensures that software is state of the art and neither outdated nor unmaintainable as part of the tendering, implementation, testing, acceptance and maintenance of software. If necessary, he also acts as a court expert in the event of a dispute.
Contracts in software development annoy many people. Most developers and testers want to program or test, not read paragraphs and formulate text passages. But contracts are not just paperwork. In the event of a dispute, they decide whether a company goes bankrupt or a freelancer is sued for damages. In the podcast Software Testing, Richie and Sebastian Dietrich talk openly about legal pitfalls and guide you through the most important points for secure contracts.
Freelancers in IT are often proud of their work and show their commitment over many hours in a project. But freelancers don't just owe their clients hard work, they owe them real project success. This means that the work must fulfill a specific goal, for example delivering functional software. If errors occur, the developers and testers are liable for them.
How can you protect yourself from being held liable for every little bug? The most important thing is to include in the contract that errors are technically normal and that the correction of minor errors is paid for on a time and material basis, not as a warranty. Sebastian Dietrich clearly explains that gross negligence cannot be excluded, but that you are not liable for slight negligence if you clarify this in the contract.
Many people believe that a contract is immediately a contract for work or a contract for services, depending on the heading or method of payment. This is a mistake. The decisive factor is what the contract actually says and how both parties understand it. Particularly in agile projects, where the outcome is often unclear at the beginning, an apparent service contract can quickly become a contract for work and services that demands the full success of the project.
In the podcast, Sebastian Dietrich describes cases where customers kept filling up the backlog, the software was never "finished", payments were not made and companies sued. The solution: formulate the contract in such a way that the client is actively involved in the process, that the focus is on the service and not on the perfect end product. Simple sentences can save millions here.
What is "state of the art"? Many people write this into contracts without realizing how vague the term is. "State of the art" does not always mean the latest of the new, but rather what has proven itself and is considered safe. In the event of a dispute, an expert is often called in to check whether the methods used are comparable with the usual standard.
For example: Is mob programming really better than peer programming? Is there any scientific evidence? No, says Sebastian Dietrich. Without studies, what counts is what has proven to be efficient and safe. It is therefore wise to agree a joint decision-making process with the customer in the contract as to how the techniques and tools used are selected.
Many people talk about test coverage, but the number of remaining errors ("residual error rate") can be more important. Sebastian Dietrich says: "If the error rate is too high, a product is not ready for acceptance. New methods such as tests with AI are exciting, but are not yet state of the art because there is hardly any research into them. Anyone who only works with this is taking a legal risk. The state of the art is always what is considered safe at the time of handover - not at the start of the project.
The contract is not meant for your friend, but for your enemy, says Sebastian Dietrich frankly. In the event of a dispute, the small, clear sentences that protect against liability and financial damage are what count. If you are unsure, you should have contracts checked before you get a rude awakening. It costs little time, but can save your life.
Software projects are more than just technology. They are legally mined areas. Those who protect themselves not only save nerves, but also save their own existence in an emergency. More clarity, less risk - and sometimes a single, well-worded sentence in the contract is enough.