What are the principles that any professional software engineer should comply with?
That’s the question I will try to answer in this blog post.
But first, let me tell you a story.
Once upon a time, there was a small team working on a critical application. The deadline was tight, and management was pushing for a release “as soon as possible.” One of the engineers hesitated: some of the automated tests were failing — minor edge cases, nothing too urgent, they argued. “We’ll fix them later,” they said. The pressure to deliver trumped the red test suite. The code was shipped. In production, the very edge cases that those failing tests covered caused a subtle bug that corrupted user data. It took weeks to identify and resolve the issue, which cost the company significant reputational damage and eroded user trust. Ultimately, the “minor” failing tests cost far more than the extra time needed to get them green.
That engineer’s hesitation — and ultimately the team’s decision to ship with failing tests — was not just a matter of expediency. It was a failure of professional ethics.
Why accepting red or failing tests is unethical
A professional software engineer does more than “just write code.” According to Robert C. Martin (often referred to as “Uncle Bob”), programming is an act of responsibility, and professionals must take full ownership of the consequences of their work. In The Clean Coder, he makes it clear that professionalism is not about compliance, but about ethics: doing the right thing even when it is uncomfortable.
Accepting a failing test — even “just for now” — violates that responsibility. It knowingly delivers sub-par or unsafe software, relying on the hope that the missing fix will come “later.” That violates the very core of professionalism, because:
- It destroys the guarantee that the code works as expected. Martin strongly argues that professionals must be confident about all the code they release, and that tests are the foundation of that confidence.
- It erodes trust — among team members, between engineers and stakeholders, and between software and its users. By shipping with red tests, you implicitly communicate that quality is negotiable. That is not what a professional does.
- It encourages a dangerous culture of “debt by default,” where shortcuts become acceptable and technical debt silently becomes the norm.
When you accept failing tests, you are not just betting on luck — you are betraying the craft.
What other thought leaders say about responsibility
This ethical stance is not unique to one author.
Kent Beck, the creator of Extreme Programming, placed “Respect” at the core of XP. Respect for your teammates means never checking in code that breaks the build or leaves tests failing. If your changes cause others pain, you are not acting professionally.
Martin Fowler has consistently argued that working software is not enough if the internal quality of the system is decaying. He emphasizes that design and refactoring are continuous responsibilities — not something to postpone indefinitely in favor of “temporary” defects.
John Ousterhout, in A Philosophy of Software Design, strongly warns against “tactical programming,” where engineers optimize for speed today and leave complexity and fragility behind for tomorrow. He argues that real engineering is strategic: reducing complexity over time and refusing to accept unstable or fragile systems.
These authors approach the topic from different angles, but they converge on the same principle: professionals think long-term rather than short-term.
A non-negotiable rule for professionals: never accept red tests
Based on both ethics and practice, there is a rule that should be treated as non-negotiable:
A professional software engineer must never accept or ship code with failing (red) tests — under any circumstances.
Red tests are a signal of broken promises. They tell you the system is not behaving as expected. To ignore that signal is to normalize dishonesty in your own work.
Robert C. Martin describes professionalism as the courage to say “no” — even to managers — when quality is at risk. Refusing to ship with broken tests is not stubbornness; it is ethical courage.
Ethics in software engineering is real
Software increasingly controls critical aspects of our lives: money, health, safety, communication, transportation, and many other domains. The idea that it is “okay for now” to ship broken software is not just naive — it is dangerous.
Accepting failing tests teaches teams to accept uncertainty as normal. It teaches them to postpone discipline. It teaches them to gamble with other people’s safety.
That is not engineering.
That is not craftsmanship.
That is not professionalism.
Professionalism is a daily choice
Professional software engineering is not about being brilliant. It is about being disciplined.
It is about refusing to lower the bar, even when deadlines are tight.
It is about refusing to normalize brokenness.
It is about choosing integrity over convenience.
If you want to call yourself a professional, then this is the standard:
Never accept red tests.
Never ship with red tests.
Never normalize brokenness.
Demand green tests. Ship only with green tests. Do it always.
Top comments (1)
Nunca normalize a fragilidade! O teste é uma rede de segurança pra lidar com toda a manutenibilidade, se deixar passar até perde o sentido da rede te avisando sobre algo. Sobre esse pensamento além testes é aí que a gente pensa melhor até em qual teste escrever pra não fragilizar a rede. A confiança é importante.