Let’s start at the beginning.

The prediction

If you work as a software engineer and regularly browse social media platforms such as LinkedIn or X, you will most likely come across an unsettling prediction:

Software Engineering will be dead in less than one year.

It is a harsh statement, but it reflects a belief that is in fact widespread. If you think about it for a moment, there is some logic to it. State-of-the-art AI coding assistants, such as Claude Code, are incredibly powerful. They have reached a level of capability that would have been hard to believe just a few months ago.

This technological reality has led many people to believe that we no longer need programming languages. We can describe software behavior in plain English, and, if the result is not what we expect, we can simply refine our words until the software behaves as we want. In this view, we do not need software engineers. Anyone can build software because coding is automated. AI has raised the level of abstraction to a point where natural language is enough to tell computers what to do.

Where, in my opinion, the prediction goes wrong

The prediction rests on two premises:

1. From natural language, AI coding assistants can generate source code (in a high-level language such as Python, Kotlin or C++).

2. From source code, compilers can generate assembly code (or a binary executable representation).

While these two statements are true, a subtle detail causes the prediction to break down: the first premise is not a deterministic transformation. Given the same sentences in natural language, there is no guarantee that we will obtain the same source code. This is because AI coding assistants do not follow a fixed procedure. They rely on probability distributions: they make choices based on what seems most likely to be correct according to patterns learned from millions of examples in their training data.

This is more relevant than it may seem. It means that we lose control of the software that we are building. Let’s illustrate it by means of an example.

A realistic example

Imagine a team that is responsible for a live production system. None of the team members are software engineers, so they lack technical knowledge. Instead, they maintain the system exclusively using AI. Suddenly, the system starts malfunctioning due to a critical bug. The team tries to fix it using natural language, but every attempt fails. What can the team do? The only option is to dig into the source code, but they can’t because they are not software engineers.

The takeaway is that a probabilistic tool cannot be held responsible for a live system, especially if it is safety-critical. There will be times when we need control: moments that demand certainty, not probability.

Those who claim that software engineering is dead would not trust the software that runs their company entirely to AI. They’d put humans who deeply know the system in charge.

Building a throwaway app quickly is one thing. Maintenance of a product with long-term profitability is another.

When software must stand the test of time, it must be built in a way that others can maintain it long after you are gone. It must be built with quality attributes (such as testability and code readability) in mind, and these attributes remain primarily the responsibility of humans, not machines.

An understandable trend

While there is no evidence that source code will lose its relevance or that professional software can be entirely developed and maintained by AI, I find the trend understandable.

My impression is that, in the software industry, many developers (and even more non-technical roles such as managers or salespeople) have never cared much about code and its quality. Technical practices such as the ones proposed by eXtreme Programming (XP) are the exception, not the norm. Any software engineer with a few years of experience has likely worked on a legacy codebase that is difficult to understand and change, or on a team that is unwilling to pair-program, write automated tests, or refactor code.

These are the people who claim that Software Engineering is dead. They have never been enthusiastic about code quality, so why would they start now? This is the perfect opportunity to ignore engineering practices without guilt.

In the era of AI, the challenge for us, software engineers, is to show that code quality (and the practices that enable it) matter today as much as they ever have, and perhaps even more.

The two audiences of code

Many people argue that we should stop paying attention to AI-generated code. After all, software engineering is dead, right?

I strongly advice the opposite.

In the age of AI, machines not only execute code; they care about meaning and intent, which makes readability relevant for machines as well. Does it make sense to stop reading code and caring about its quality now that code has two audiences: humans and machines?

AI agents do not inherently produce well-crafted code. They are not optimized for craftsmanship during their training. They may miss abstractions, introduce duplication, or choose inappropriate variable names, for example. It is our responsibility to address these issues. Continuous refactoring is the only way to improve code quality over time, and higher-quality code reduces the likelihood that AI agents misinterpret your intentions when reading code, making AI agents less likely to make mistakes.

Continuous refactoring is also crucial at the level of system architecture. There is a limit to how much a person can hold in mind at once, and the same applies to AI agents. The more you ask an AI agent to focus on, the less attention it can give to any individual part. Context should be minimized to make code easier for AI agents to understand. This is why separation of concerns is such an important design principle. Just as higher modularity reduces cognitive load for humans, it also reduces contexts for AI agents.

The problem is that AI agents tend to struggle at larger scales because they are better suited to local context, not global reasoning. This leaves software architecture primarily a human-driven activity.

Engineering practices

The relevance of software quality strongly suggests that Software Engineering is far from dead, but we can make the argument even stronger. Software Engineering is not only about code. It encompasses all the engineering practices that enable quality and sustainable delivery of value to customers. Unsurprisingly, the engineering practices that have proven effective for decades seem to be the perfect fit for this new era of AI-assisted development.

What role do these practices play?

AI agents have undoubtedly increased coding speed, but this does not necessarily translate into delivering more value to users in less time. Ultimately, it depends on the team.

• In a team where code is not frequently integrated into the main branch, increasing coding speed will lead to more merge conflicts, and will make these conflicts bigger and harder to resolve.

• In a team where deployments are not automated, increasing coding speed will create more work for operation teams.

• In a team where testing is treated as an after-development phase, increasing coding speed will create more work for QA teams and more bugs to address later, when they are more expensive to fix.

• In a team where collaboration is weak, increasing coding speed will result in more rework and misalignment.

In such a team, coding is not the bottleneck; the way the team works is. Optimizing a non-bottleneck in a system that has real bottlenecks will not make the system more efficient. It will probably make it less so.

The key to being effective with AI coding assistants is to be effective without them [1]. A team that works in small batches and follows time-tested practices such as refactoring and continuous delivery will benefit from a huge boost in productivity when using AI tools. A team that lacks discipline may feel an initial surge in coding speed, but it will lose traction with each passing day, as technical and comprehension debts accumulate.

Healthy and productive teams

In addition to engineering practices, the composition of teams within a software company can also affect how effectively the company leverages AI.

In a company where teams are organized around specific skill sets (such as QA, front-end, business-analysts, DevOps, etc.), customers will not receive value any faster because delivering software requires extensive inter-team communication. In this context, coding is clearly not the bottleneck, so accelerating it will have little positive impact.

Note that the same bottlenecks can arise within a team if members are overly specialized. To fully benefit from AI, teams need to be cross-functional and team members must maintain healthy and effective communication.

Last but not least, the team requires autonomy. In command-and-control hierarchies, where decision-making is slow and managers do not trust the team, increasing coding speed will have little effect because the team will spend most of its time waiting for approvals. The team must be empowered to make decisions on the spot, as they are needed, in the same way as continuous activities such as code integration, testing, or refactoring.

Conclusions

Contrary to what many believe, Software Engineering is far from dead. Coding is not fully automated, and even if it were, Software Engineering is not only about code. Teams must be effective without AI to fully benefit from AI coding assistants. Engineering practices such as continuous integration and refactoring, which promote clean and readable code, are essential to ensuring that AI adds value, rather than becoming a source of technical and comprehension debts.

There is no denying that state-of-the-art AI coding assistants are remarkably capable today, but the main implication is simply that software engineers have an incredibly powerful tool at their disposal.

Coding has changed forever. Software engineers must adapt to this new era, just as they have countless times before, at historical milestones such as the introduction of the first compilers and high-level languages, or the rise of the World Wide Web. This time is no different.

References

[1] Jason Gorman, The AI-Ready Software Developer (2025)

Here, in this follow-up post, I shift focus from these best-case scenarios to explore a more realistic situation where quality should not be compromised: introducing new long-lived functionality into the codebase of a live production system.

Introducing new functionality into our production system brought to light several challenges that may be easily overlooked by teams that are beginning to adopt AI tools. Below, I describe these challenges in detail and outline strategies for addressing them. These strategies will allow you to speed up your development process while keeping quality high in the age of AI.

1. Misunderstanding the system

In an AI-powered IDE (such as Cursor), asking an agent to implement a new feature may require the agent to fully understand and reason about your entire project. Any gaps or misunderstandings will lead to problems. For example, the agent may:

• Overlook files that should be modified.

• Suggest changes to files that should remain unchanged.

• Generate tests for unintended behavior.

• Miss tests for expected behavior.

Many factors can lead an agent to misunderstand your system. Some of these factors are intrinsic to the nature of the project and are difficult to address. For example, the system that I describe in my previous post is event-driven. Event-driven systems are inherently decoupled: an event is published and multiple subscribers react, each potentially located in distant and seemingly unrelated parts of the system. Establishing these logical connections by inspecting the code is a difficult task, even for an AI agent.

Other factors, however, are within our control, and we can take proactive action to help the AI agent interpret our system correctly.

1.1. How to mitigate this problem?

Harold Abelson and Gerald Jay Sussman stated in their seminal book “Structure and interpretation of computer programs”:

Programs must be written for people to read, and only incidentally for machines to execute.

Martin Fowler expressed a similar idea:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

This way of thinking has positively influenced many software engineers for decades, but it is misaligned with the current technological reality. In the age of AI, machines not only execute code; they care about meaning and intent, making readability relevant for machines as well.

Clear and intent-revealing variable names, combined with strong separation of concerns, a well-designed domain model and a comprehensive test suite (which offers unambiguous examples of the system’s actual behavior) are now more relevant than ever. Writing high-quality code reduces the likelihood that AI agents misinterpret your intentions, making AI agents less likely to make mistakes.

In the AI era, we must write clean, readable code for both humans and machines, as both need to understand it to apply changes safely and effectively.

2. Loss of control

Have you ever engaged in pair programming with a driver who moves at a frenetic pace, jumping between files and changing large chunks of code so quickly that it seems impossible to keep up?

Welcome the cowboy (or cowgirl) driver.

The cowboy driver gives little consideration to the navigator. The only priority is speed and the navigator is an obstacle, not a partner. When I am working with such a driver, I feel that I lose control. I am unsure whether new bugs are being introduced or whether all relevant tests are in place. I have no time to gather my thoughts and offer meaningful suggestions.

AI agents make this situation more likely. The driver will be producing more code in less time, since most of the code will be AI-generated. This leaves the navigator even less time to inspect it, unless the driver is disciplined about code reviews.

Note that this problem can also arise when programming alone. An AI agent is like a pair-programming partner that produces code at great speed. It is tempting not to review the code carefully. When this happens, you lose control and the snowball effect will take over: quality will deteriorate increasingly fast with each passing day.

2.1. How to mitigate this problem?

To mitigate this problem, you need to slow down to regain control. A technical practice that is well suited to this purpose is Test-Driven Development (TDD). TDD encourages progress in tiny steps, writing one test at a time and ensuring each test passes before moving on to the next test.

From my brief experience with AI-powered IDEs, I have found that, when working with AI agents, you can take slightly larger steps. An AI agent can write a test and make it pass in a single step; or it can handle multiple tests at once, passing them in one go. Your level of confidence will guide you when deciding the size of your steps.

Regardless of your choice, review your code carefully and do not skip refactoring. Regular refactoring keeps you close to the code, improves its quality over time, and ultimately lets you move faster in the long run.

3. Weakened learning loop

Software development is inherently iterative. You add a feature to the system, show it to customers, gather feedback, and iterate. At a lower level, you define expected behavior as an automated test, make the test pass, refactor, and iterate by writing the next test.

There are many levels in between, but they all have one thing in common: the learning loop. Each iteration – whether with a customer, a teammate, or yourself – produces valuable new knowledge.

When AI agents enter the picture, the learning loop is weakened. Developers interact less directly with the code and this causes two main problems.

1. Reduced familiarity with the codebase. When most of the code is generated automatically, developers spend less time reasoning about it. This is especially problematic for new team members, who need hands-on interaction with the code to understand how the system actually works.

2. Eroded technical skills. Much like forgetting how to divide manually once we start relying on a calculator, writing less code can negatively affect your abilities. Over time, depending heavily on AI can make it harder for you to do technical work without automated assistance. Some people may argue that you will not need these technical skills in the future, but no one can reliably predict how the field will evolve, and sacrificing foundational skills for short-term convenience is a risky trade-off.

3.1. How to mitigate this problem?

It may sound obvious, but you can reap the benefits of interacting with the code by interacting with the code. When you ask an AI agent to generate code, do a thorough code review and do not hesitate to edit the code manually, for example, to add a test that the AI agent missed.

Another great way to stay engaged with the code is through refactoring. It has always been tempting to skip refactoring. Most developers make the code work and move on to the next feature, leaving behind suboptimal solutions. You can set yourself apart by making small improvements whenever you identify an opportunity. Not only does this improve code quality, but it also has a positive impact on your learning.

Further advice

You can also follow these general guidelines to fully leverage AI agents and mitigate the problems described above:

• Be specific. The AI agent knows less than you do. Explaining a technical solution in plain English can be challenging, but it is essential to provide as much context as possible. Imagine that you are explaining the problem to a brilliant junior developer. Despite being highly productive, they still need every detail to understand the problem fully.

• Write commands and rules. In AI-powered IDEs like Cursor, you can store coding conventions and good practices as rules or reusable commands. By doing so, you reduce errors, maintain consistency across the codebase, and it also allows you to focus on problem solving (instead of repeating the same instructions over and over).

Conclusions

AI agents can accelerate software engineering, but they introduce challenges that, if not carefully managed, can negatively affect quality and the health of the team.

This post outlines three of these challenges and proposes practical ways to address them. Practices such as TDD, refactoring and disciplined code reviews, which promote clean and readable code, are essential to ensuring that AI adds value, rather than becoming a source of technical debt.

AI agents will make you produce bad code faster, if you are careless; but, if you are disciplined, they will help you produce good code just as quickly. AI agents act as amplifiers of your current outputs. Software teams that harness AI wisely will deliver value more effectively, while those that use it unwisely will gradually lose their ability to satisfy customers, slowing down as problems accumulate.

We are a development team that is strongly committed to software quality, since it is what enables us to deliver business value at a sustainable pace. Extreme Programming (XP) practices, such as Test-Driven Development (TDD) and pair programming, help us keep quality high and also counteract the natural tendency of software to degrade over time.

When we started using AI – with no prior hands-on experience – we were naturally worried about how AI would impact the quality of the software that we delivered. AI might help us deliver value more quickly, but the speed should never come at the expense of software quality, as this would compromise sustainability.

Despite our concerns, we did not conduct empirical assessments to measure code quality. Instead, we relied on regular communication with stakeholders to learn about their perception of how the team’s delivery pace was evolving. We also paid close attention to the code, carefully monitoring whether it was becoming more manageable or more challenging to work with.

I will discuss how to keep – even increase – quality in the age of AI in an upcoming post. In this post, I will relax the keep-quality-high restriction. I will describe four situations where quality is less critical, or where you can expect the quality of the generated code to match the quality of your current code. In these four specific cases, LLMs can offer a significant increase in productivity with minimal concern.

Before we dive in, let’s look at a running example that will help me illustrate the key insights in each section of this post.

A running example

Let’s say that your team is building a WhatsApp chatbot for an insurance company. Whenever a user of the insurance company’s website provides their contact details, they are classified as a potential customer and the bot initiates a conversation. It typically begins with a series of profiling questions that are designed to learn more about the user’s needs and preferences.

Some of the profiling questions that the bot may ask are:

• What type of insurance policy are you looking for?

• Are you currently insured with any company?

• What type of coverage do you have?

Other questions may be more specific, tailored to a particular type of insurance policy:

• Do you own a home?

• How old is your home?

• What type of property do you live in?

The information gathered through these questions helps the bot suggest the most relevant insurance options to users, sometimes adapting the recommendations to better suit individual needs.

1. Throwaway code

One of the services of the WhatsApp chatbot calculates the policy price given a specific user profile. This service is deployed as an AWS Lambda and its logs are available through AWS CloudWatch.

Suppose that you need to download the CloudWatch logs of the past two months and prepare a statistical report. This is a one-off task that has been assigned to you to meet the needs of a particular stakeholder. While you could perform the task manually, the volume of data makes it impractical. Automating the process via a script is a far more efficient solution.

The key observation here is that the script will have no long-term use; therefore, code quality is not a primary concern. This is the perfect opportunity to leverage LLMs for code generation. If you describe the task in natural language and sufficient detail, you will have the script in a matter of seconds.

Keep in mind that the script may not fully meet your needs on the first try, but it will provide a solid starting point. You can then tweak the script manually, or you can also refine your prompt by adding more specific details to guide the LLM in the right direction.

2. Repetitive tasks

Suppose that a user sends a video or a text message in a WhatsApp conversation. To respond to this action, the WhatsApp chatbot must be implemented as an event-driven system. Whenever a user action occurs, the system is notified by Meta (or any other intermediary) through a WhatsApp Message Received event. In this event-driven context, most new features – at least, those triggered by incoming WhatsApp messages – are added to the system through a new event handler that invokes the appropriate use-case class.

For example, let’s say that you need to add the following feature: if the user types “stop”, you must stop sending marketing messages about new insurance offers. To implement this feature, you will create a new event handler that invokes a stop-marketing-messages use case whenever a “stop” message is received.

This new event handler may be the tenth, eleventh or n-th that you implement. Since they are all similar, if you ask an LLM to do it, the LLM will have plenty of code to reference and base their decisions on, making its output highly likely to meet your needs, both in terms of value and code quality. You don’t have to build the event handler (and its tests) from scratch – just ask the LLM to do it and the LLM will generate the code almost instantly.

3. Experimental context

Let’s say that the insurance company needs to learn about insurance claims or accidents that the user may have had in the last three years. Your team may obtain this information via a new profiling question in the WhatsApp chatbot. However, this approach raises a few concerns.

Many users may be unwilling to answer and could abandon the conversation, resulting in the loss of potential customers. Furthermore, whether users answer or not may be affected by the timing of the question. For example, a user may ignore the question if it appears at the start of the conversation, but they may respond if the question is asked later. In any case, it is essential to understand users’ behaviour to offer the best possible experience and reap maximum benefit.

Your team decides to run an A/B test. In one variant, the new question is placed at the beginning of the conversation, while in the other, the question is introduced later in the series. The goal is to determine whether the order of the questions affects user responses.

In this scenario, you know that the code you add will be removed – or, at least, modified to retain only one variant – once the test concludes.

An LLM can save you a significant amount of time. If the prompts that you used to run the A/B test are available – for example, you stored them as a plan – then you can simply ask the LLM to remove one variant or both.

4. Navigating legacy code

Imagine that you are a new member of the team and discover that the WhatsApp chatbot does not initiate conversations with all users who submit their contact information on the company’s website. In order to understand the conditions that trigger new conversations, you examine the codebase. However, you soon realize that the task will be challenging: the logic is scattered across multiple files and the code is difficult to follow.

You can ask an LLM to interpret the code for you and explain the conditions in plain English. Understanding natural language is easier than understanding code, especially if the code was not developed with readability in mind.

Note that the questions you pose to the LLM may be difficult to answer – they may require extensive reasoning and analysis of large fragments of code – but simpler questions can be just as valuable. For example, asking the LLM to explain an individual function, which typically yields a response within seconds, can be extremely helpful when navigating legacy code.

Conclusions

This post outlines four scenarios that give software engineers unique opportunities to leverage LLMs and accelerate their development process. In these scenarios, the usual concern about LLMs – the quality of AI-generated code – is far less critical, which enables substantial productivity gains.

In a subsequent post, I will step away from this “happy-path for AI” and explore a more realistic and challenging case: introducing new long-lived functionality into an existing codebase. I will discuss the key challenges involved and strategies that we can use to address them.

Even though I belong to the second group, when I am dealing with legacy code I do not get to choose.

Adding tests to legacy code can be painful. Very painful.

When you write tests first, you know (or, at least, you have a fair idea about) what the new code needs to do. You have expectations for the new code, so you can capture these expectations as tests. In contrast, when you add tests to legacy code, your knowledge about the code can be a major limiting factor. Legacy code is convoluted, obscure, and hard to read, so, most often, you don’t understand the code well.

Lack of understanding is an insidious problem. Without a well-grounded approach, adding tests to an unfamiliar system is like crossing a busy avenue blindfolded: you may succeed, but the chances of a negative outcome are high. You may produce tests that are not significantly better than no tests at all, and this will make leaving the code untested a reasonable alternative.

This is a serious problem. As Frederick Brooks says: “the only constancy is change itself” [1]. The need for change always arises, and you need a comprehensive suite of tests to modify code safely.

As a solution to this problematic situation, Michael Feathers proposes a less-conventional approach to testing that is called characterization testing [2].

In this post, I describe what characterization tests are, what benefits they bring, and how we can write characterization tests effectively.

What are characterization tests?

A conventional way to look at automated tests is as documents that describe the expected behavior of the system. The feat of “tests as documentation” is difficult to achieve in legacy code, however. If we don’t understand the code well, the intent of the tests is not in our head; therefore, we don’t have expectations that we can easily articulate. Writing readable and intent-revealing tests seems impossible in this context.

The way out of this dead end is a shift in perspective. If you, just for a moment, relegate documentary value to a secondary role, you realize that writing tests just to invoke the system and observe its output offers insight and learning.

This perspective is what characterization tests exploit. Characterization testing relaxes the initial readability focus so that you can observe the actual system in operation and capture your observations as automated tests. As your knowledge grows, you will improve the readability of the tests, but the focus will be on making your observations more explicit and intent-revealing.

Characterization tests allow you to invoke the legacy code, observe what it does, and understand its behavior. When you write characterization tests, you do not document your expectations. You characterize the actual behavior of the system.

Benefits of characterization testing

The main benefit of characterization testing is that you improve your understanding about the legacy code. You add one test at a time, and this allows you to learn about the system incrementally.

This is not the only benefit, however. While you improve understanding, you gain a suite of tests almost for free. This suite, similarly to any other form of automated testing, helps you preserve the behavior of the system. If you change some behavior unintentionally, the characterization tests will notice and warn you. Characterization tests give you a safety net that reduces risk when applying changes.

An equivalent way to look at the benefit of risk reduction is bug prevention. If you run the tests often enough, every time they catch an error, the live time of this error has been a few seconds or minutes, instead of days, weeks or even months. Characterization tests help you detect errors early, when they are cheaper to fix.

Characterization tests help you improve your understanding of legacy code, reduce risk when applying changes, and make errors easier to detect and fix.

Preserving behavior of legacy code

A common argument against characterization testing is that legacy code is often buggy. Why would you want to preserve behavior?

When a system has been in operation for a non-negligible amount of time, users depend on the way it works. Some behavior may look defective to you, but it is possible that users rely on that behavior.

Michael Feathers says:

When a system goes into production, in a way, it becomes its own specification. We need to know when we are changing existing behavior regardless of whether we think it's right or not.

Preserving behavior is important, but, when you write characterization tests, it is common to come across behavior whose correctness raises reasonable doubt. If you suspect that some behavior is a bug, get the opinion of other stakeholders. If it is a bug, go ahead and fix it.

How to write characterization tests

There is one thing that you will not do when you write characterization tests: looking at functional specifications.

Functional specifications, if they exist, state what the system is supposed to do, not what it actually does. We don’t look for mismatches between the behavior that we expect and the behavior that the system exhibits. Characterization testing is not bug search; it is characterization of actual behavior. Therefore, we will look where the only truth about the system behavior lies: the code.

Looking at the code to write tests is not a bad thing. Characterization tests are white-box tests, and we can use this fact to our advantage. For example, we can use code coverage and mutation testing tools to help us decide what tests to write next. Assisted by these tools, we can achieve a comprehensive suite of tests more easily.

An algorithm for characterization testing

Michael Feathers suggests the following algorithm to write characterization tests:

1. Put a piece of code in a test harness; that is, call it from a test.

2. Write an assertion that you know will fail.

3. Let the failure tell you what the behavior is.

4. Change the test so that it expects the behavior that the code produces.

5. Repeat.

Step 1 is usually the hardest. You may want to call a method from a test, but, to do so, you need to instantiate the class that contains the method. Instantiating this class can be tough if it has undesired side effects, such as accessing a database or loading an expensive resource. You may need to break dependencies first.

An example of characterization test

Steps 2 to 5 are the steps where you write characterization tests.

Suppose you want to add tests for a function called “padString”. You look at the code of this function, and, apparently, it fills an input string number with 0s so that it contains a certain number of digits. It also looks like it removes certain characters. However, you are not sure because the code is hard to understand.

Looking at the code, you are almost certain that, if you pass “3.45” into the function, it will not return “abc”, so you write the following failing test:

The name of the test is deliberately vague. You don’t have enough knowledge at this point to come up with a good intent-revealing name that states the behavior under test.

You run the test, and, as expected, it fails. You look at the assertion failure and observe that the actual output of the method is “0000000345”. Now, you know more that you did before running the test.

At this point, you can update the test so that it asserts (and preserves) the actual behavior of the “padString” method. And, if you feel comfortable enough, you can also improve the test name:

After the test update, you can continue to write more tests. You will stop when you are satisfied with your understanding of the “padString” method and when the tests allow you to apply safely the changes that you want to apply.

Conclusion

Characterization tests offer a different perspective on testing.

Unlike test-first approaches (such as Test-Driven Development), the focus is not on driving development with tests. Unlike other test-later approaches (such as manual exploratory testing), the focus is not on finding bugs. Instead, characterization testing focuses on (1) characterizing the behavior of legacy code to understand what it actually does and (2) preserving its behavior under changes.

Increasing understanding about code is key to minimize the chance of errors when we modify it. This chance of errors is also greatly minimized by the suite of tests that we get almost for free.

References

[1] The Mythical Man-Month: Essays on Software Engineering. Brooks, F. P. (1975, 2ª ed. 1995).

[2] Working Effectively with Legacy Code. Feathers, M. Prentice Hall Professional (2004).

Some of these problems are:

• The system is hard to understand.

• The system is hard to change because every simple change forces you to modify many other parts of the system.

• The system is immobile because its parts are so tightly coupled that they cannot be reused independently.

Many books offer techniques to deal with these problems. A notable example is Martin Fowler’s refactoring book, which describes ways to improve the structure of code without altering its observable behavior. Other examples are Code Complete by Steve McConnell and Working Effectively with Legacy Code by Michael C. Feathers.

Reading books about good Software Engineering practices is a great way to grow in your career. However, I have observed that some developers tend to apply the acquired knowledge to production code only: they do not treat test code with the same care.

This is unfortunate. Test code should be kept to the same quality standards as production code. Otherwise, the quality of the production code will decline over time because you cannot refactor safely (without good tests).

This is why smells in test code are as bad as smells in production code; and they can even be worse.

If the production code has design smells but the tests don’t, the tests give you a safety net that allows you to fix the smells through refactoring. But, when the problem is in the tests, how do you fix it?

This post is not about techniques to improve test code. Rather, it describes five common test smells that can help you identify when it may be necessary to take corrective actions.

1. Fragile tests

When some behavior changes in the system, it is expected that the tests that assert the old behavior fail. After all, the system does not exhibit the old behavior anymore.

This is the very reason why we write tests in the first place. We may change the behavior of the system unintentionally, and, when this happens, we want the tests to fail and warn us. This is how tests prevent bugs.

But, if we modify code without changing behavior and tests fail anyway, then the tests are failing for no valid reason.

These tests are fragile.

A fragile test is a test that breaks easily. It is a test that fails when it should not fail. It is a test that imposes a heavy burden because we are forced to revisit it often.

When we are forced to revisit tests more often than we should, we cannot change and improve code comfortably.

A good suite of tests makes refactoring easier. When the tests are fragile, the effect is the opposite.

2. Slow tests

Tests may be slow.

A common cause is access to external sources, such as the file system, a database, or a distributed service.

The most obvious consequence of slow tests is that productivity decreases. We waste precious seconds every time we run the tests.

But there are other, less obvious, consequences: our ability to prevent bugs decreases and bugs become more expensive to fix.

Our ability to prevent bugs decreases because the key to bug prevention is getting immediate feedback about code changes. If we don’t get this feedback, we can introduce bugs and discover them the next day, or the next week, if we ever do it. We get immediate feedback by running the tests with every change to the system; however, this is not practical if the tests are slow.

A nasty side effect is that bugs suddenly become more expensive to fix because they are discovered late, when the context is not fresh in our minds.

When tests take too long to run, we can't run them often enough. Productivity decreases and we lose our ability to deal with bugs in a cost-effective way.

3. Obscure tests

Automated tests have some non-obvious benefits.

One of them is that automated tests give us examples about how the system is used at the code level. Therefore, they help us understand the system better.

Another benefit is that tests offer defect localization. Tests must fail when we introduce defects; that is, when the behavior of the system changes in ways that it should not change. Ideally, the tests will help us locate the problem easily.

If we want the tests to be useful code examples and to help us locate defects effectively, the tests must be readable, not obscure. If the tests are obscure, their benefits are minimized because it is not easy tell what the tests are testing. We can only reap the benefits of testing when the cause-effect relationship between the inputs and the outcomes of the tests is crystal-clear and easy to identify at first sight.

Tests must be intent-revealing; otherwise, they lose most of their value. The system becomes harder to understand and defects harder to diagnose.

4. Tests with conditional logic

When you introduce conditional statements and loops in a test, the complexity of the test increases. After a certain (very low) threshold, you cannot be sure that the test is bug-free and it works as expected.

You need automated tests for the tests.

But then you need tests for the tests of the tests. When does this recursion stop?

The “trick” is to write tests that are so simple that they can be easily seen correct, thereby not requiring testing. This happens, for example, when tests contain only a few sequential statements.

When a test contains branches or loops, it is more complex than it should. Complex tests can hide subtle bugs.

5. Assertion roulette

Tests must verify a single condition.

Another way of expressing the same concept is that tests must assert a single expected behavior.

This is easy to say. However, it is hard to get an idea about what exactly a single condition (or a single behavior) is. These notions are subjective.

What works best for me is thinking about tests in terms of their three well-known phases: arrange, act, and assert.

Testing a single condition does not imply that there is only one “physical” assert statement. It implies that there is a single act phase and a single assert phase within the same test. We avoid a series of act-assert pairs.

The problem with alternating act and assert phases in the same test is that, when the test fails, it is hard to determine the failing assertion because the test verifies multiple behaviors. When this happens, we say that we are experiencing assertion roulette.

Tests should have only one unambiguous reason to fail.

Conclusion

If you think there are test smells that do not appear in this post, you are right. The nature of the problems that can arise during testing is too diverse to fit in a single post.

For example, another type of test smell is erratic tests: tests that behave in an apparently non-deterministic way. Sometimes they pass and sometimes they fail, and it is not clear why this happens or how to obtain predictable results.

Despite the necessary incompleteness of this post, I hope that it gives you an idea of how bad tests look like and the problems they can bring. Hopefully, this will motivate you and, next time you come across a bad test, you will feel the urge to act and fix it.

The post covers the part where I discuss about the notion of robust tests and how unit size impacts robustness.

In that post, I leave one question unanswered: how can we decide the right size of a unit?

This question is important. After all, there seems to be correlation between the size of the units under test and test robustness.

Here, I address the question from two different perspectives — code structure and behavior — and I show that each perspective aligns with a different style of TDD — outside-in and classic.

As we will see, both TDD styles help us write tests that are robust.

Outside-in TDD is about code structure

In outside-in TDD, you write system-level scenarios (i.e., customer tests), and then you make them pass by proceeding towards inner layers of the software, guided by lower-level tests. At each step, you identify responsibilities and distribute them in different modules (the systems under test, or SUTs). This approach requires test doubles (a.k.a. mocks) to stand in for the modules that are not developed yet.

Test doubles can be seen as a design tool. When we are working on a module, we identify its needs; then, we decide whether the current module implements these needs or delegates them to depended-on modules. In the latter case, test doubles help us design the required interfaces.

Observe the relevance of code structure. We analyze responsibilities, and then we decide which modules to create, how they interact, and where to place test doubles. The resulting modules and test doubles impact the size of our units and the tests that we will subsequently write.

Deciding unit size

In this talk, Sandro Mancuso explains how we can reason about where to place test doubles.

Consider a class A that uses classes B and C. If you remember UML, you know that there are two types of associations: composition and aggregation.

In composition, B and C can be considered as part of A. If we incorporated B and C into A, A would still be cohesive. In this case, it makes sense to consider the three classes as a unit.

For example, let’s suppose A implements a tax-calculation algorithm. The algorithm checks marital status, sources of income, etc. These checks can go in different classes (B and C) but, if they didn’t, A would still be cohesive because all the logic has the same responsibility.

When we have aggregation, B and C are not part of A. If we incorporated B and C into A, this class would not be cohesive. In this case, three units may make more sense.

For example, let’s suppose A implements the check-out process of an e-commerce application. This process involves several steps: payment, user notification, etc. Each step is complex, so it can go in a separate class (e.g., B can deal with payment and C can be an email service). If we incorporated B and C into A, this class would deal with unrelated responsibilities. Therefore, it makes sense to test the check-out process in isolation and mock the other classes.

Common pitfalls

We must watch out for common pitfalls in outside-in TDD.

• Small units: overuse of test doubles leads to small units, higher coupling, and tests that are less robust.

• Test class per production class: in extreme cases, the structure of the tests will mirror the structure of the code. This negatively affects robustness: every time we remove classes, tests will fail.

• Breaking encapsulation: when we focus on code structure, it is tempting to test every method in every class, even if they are private. Private logic changes often, so tests will break often.

How to increase robustness?

Backtracking. Once the modules in the inner layers are available, we can remove test doubles to increase the size of the units. We can also delete unnecessary tests.

But remember that small units also have benefits. You will not always remove test doubles (or tests), but this possibility is a good resource to have in our mental toolbox.

Classic TDD is about behavior

Classic TDD, as described by Kent Beck in the “Test-Driven Development by Example” book, focuses on behavior, and code structure plays a less prominent role.

This behavior-centric perspective was not obvious to me when I read the book. I became fully aware when I watched this brilliant talk by Ian Cooper, where he makes the following observation:

Adding a new class is not the trigger for writing tests. The trigger is implementing a requirement.

Creating a new structure of code, such as a function or a class, is not sufficient reason to write new tests. You write new tests when the system must exhibit new behavior.

This is how behavior drives development. You specify one behavior at a time, as automated tests; and, every time you write a new test, you make it pass, making sure that the test runs in isolation from other tests — when tests are independent, they are more robust.

And you don’t use test doubles, other than e.g. to replace external entities that introduce indeterminism or negatively affect speed. You don’t isolate units of code. The unit of isolation is the test, not the system under test.

This is why the popular notion of unit test does not match classic TDD.

This is explicit in Kent Beck’s book. He only uses the term “unit test” once: to say that tests in TDD are not unit tests:

Kent Beck uses the term “small-scale tests”. Other terms are “developer tests” (by Ian Cooper) and “micro tests” (by GeePaw Hill). The common factor is the focus on behavior, not code structure.

To give us a feel for what behavior looks like, Kent Beck offers some examples in his book.

When he discusses about tests, he states behavior: “we need to be able to add amounts in two different currencies”. He does not say: “we need to call an add method in a MoneyCalculator class". No one gives you such a requirement.

So, when you formulate tests (e.g., using the Given-When-Then notation), make sure they state behavior:

• GIVEN: two positive integer numbers.
• WHEN: we multiply the numbers.
• THEN: we obtain correct multiplication as a result.

Not code structure and implementation details:

• GIVEN: two 32-bit positive integer numbers.
• WHEN: we invoke the multiply method on the Calculator class.
• THEN: the method returns the correct result as a 32-bit integer number.

Advantages of behavior-oriented tests

The focus on behavior of classic TDD has several advantages:

• Tests are more robust: code structure are volatile implementation details; behavior is at a higher and more stable level of abstraction.

• Tests are more intent-revealing: when tests verify small units of code, it may be hard to see the big picture. Tests that specify high-level behavior allow you to understand requirements better.

Conclusion

Classic TDD focuses on behavior, while code structure plays a more central role in outside-in TDD.

In outside-in TDD, you make some design decisions upfront, and these decisions affect the resulting code structure, the size of the units, and the tests that you write. Test robustness depends strongly on unit size. By contrast, in classic TDD, upfront design is minimized; design emerges as you make tests pass and refactor. The units of isolation are the tests, so test robustness depends on this isolation and on the focus on high-level behavior.

Outside-in TDD is not all about code structure; you also specify behavior: the behavior of isolated units of code. Classic TDD is not all about behavior; you need code structure to access the behavior in the system. But tests are unaware of internal implementation details; that is, tests have no knowledge of how the behavior is partitioned.

For more details on the topic of this blog post, you can watch my talk at the TDD conference here:

It was a historic event. The lineup included big names such as GeePaw Hill and one of the original signatories of the Agile Manifesto: James Greening. Kent Beck himself - the (re)inventor of TDD - announced the conference in his Twitter account, which, along with the effort of the organizers, helped reached the non-negligible number of 2000 people registered.

The conference covered a wide range of topics, including a talk about TDD in embedded systems by my friend Francisco Climent, and also a memorable live demo of Test && Commit || Revert (TCR) by organizer Alex Bunardzic.

The event was broadcasted live on YouTube. You can find the full recording here:

I had the honor to talk in this conference.

The title of my talk was:

"On the relationship between units of isolation and test coupling - How to write robust tests with TDD".

I admit that this title reads like an academic paper. This is not necessarily bad, but, if you are not used to this type of writing, the title may not immediately convey to you the message that I want to express.

Hopefully, this post will clear things up for you. Here, I explain the key concepts of my talk: robust tests, test coupling, and units of isolation. In subsequent posts, I will build on this foundation to explain how understanding these concepts will help us write robust tests using TDD.

You can watch my talk here:

Robust tests

It is expected that tests fail when the behavior they verify changes.

This is how tests prevent bugs. We may change the behavior of the system unintentionally, and, when this happens, we want the tests to fail and warn us. Bug prevention is one of the main benefits of automated testing.

But, if behavior does not change and tests fail anyway, then we have tests that fail for no valid reason.

These tests are fragile.

A fragile test is a test that breaks easily. It is a test that fails when it should not fail. It is a test that imposes a heavy burden because we are forced to revisit it often.

Tests should not be fragile; they should be robust.

Robust tests only fail when they should. We can change and improve the structure of the code without altering observable behavior and the tests remain green. This is how tests become a valuable aid, not a burden.

Automated tests should aid refactoring, not impede it.

Test coupling

The main reason why tests become fragile is coupling.

Coupling kills software. This is true for both software applications and test code. Software modules must be loosely coupled to each other. Automated tests must be loosely coupled to the system under test.

To illustrate test coupling, let’s suppose we have a class A that uses two classes B and C. We could reasonably write the following test:

Here, for simplicity, I am loosely speaking about classes B and C as if they were functions, but I think you get the idea.

The design of this test has an important implication: the test knows all the classes (A, B and C). This may be too much knowledge for a test. If we want to edit or remove one of the classes, or add new classes, the test will probably need to be updated. This is high coupling.

This test smell is sometimes called overspecified software. A test is a specification of behavior, and this test is specifying a lot. It specifies how class A must work internally. It’s specifying the exact algorithm; not what class A should achieve or the results that it should obtain. The test is coupled to the implementation details of A.

But this type of testing is not the only way to test software. Remember the notion of encapsulation. We could write a test that has a single dependency with A and is unaware of classes B and C. For example, a test can invoke a method in A and assert that the method returns a specific value.

In this case, we can modify B or C, remove any of them or add new classes, and the tests will not need to be updated. This is how tests become robust. This is low coupling.

Units of isolation

One of the implications of the dependencies that the last picture shows is that classes A, B and C form a unit of isolation: when the tests run, code in A, B and C (and only in these classes) will be executed.

Here, class A acts as an interface or facade for the tests, and classes B and C are implementations details that are internal to the unit. The tests are unaware of these implementation details, and, therefore, the coupling is low.

This contrasts with the first example, where B and C had to be mocks so that the expectations of the test could be set in the arrange step. In this case, only code from A is executed when the tests run, and, therefore, A is the unit of isolation.

Apparently, the notion of unit is important and related to test coupling. In the high-coupling example, the unit is smaller; in the low-coupling example, the unit is bigger.

This reasoning suggests that the bigger the unit, the better, but it is not so easy.

When a test fails and the unit under test is small (e.g., a single method or a single class), it’s more likely that we can identify the cause of the problem easily. However, higher coupling increases fragility, and, consequently, unnecessary rework.

It’s a trade-off between defect localization and maintenance costs.

Conclusion

Unit size impacts test coupling, and, as a consequence, the fragility of the tests. Furthermore, we saw that both small and big units have advantages and disadvantages.

This naturally leads to the question: how can we decide the right size of a unit?

In subsequent posts, I will explore how we can address this question. And I will also show that, if we follow classic TDD, we can obtain robust tests by looking at units of isolation from a slightly different perspective.

This should come to no surprise.

The ideal number of parameters for a function need not be the same as the ideal number of parameters for another function. Furthermore, even if we focus only on a single function, the perceptions of different software engineers (who may have different backgrounds) will vary.

The issue is very subjective.

Proof of this subjectivity is that, if we look at several well-known resources, we will find different opinions.

The Code Complete book advises us to limit the number of parameters to about seven. The reason is that seven seems to be a magic number for people’s comprehension: people generally cannot keep track of more than about seven chunks of information at once.

Not surprisingly, the Clean Code book adopts a more aggressive stance, asserting that three arguments should be avoided whenever possible and more than three requires very special justification.

This rough upper bound of three parameters is closer to how I feel. Around four parameters, I start to feel uncomfortable, and my feelings get increasingly worse when I reach five parameters or more.

Five parameters or more may seem uncommon to you, but plenty of codebases are littered with functions that have six, seven, and even more. This is unfortunate because long lists of parameters severely degrade software quality.

Raising awareness of the problems of long lists of parameters, and showing how we can shrink these lists, is the main motivation of this post.

Hopefully, next time you come across a long list of parameters, you will feel motivated to refactor the code towards smaller, more cohesive, and higher-quality functions.

1. Problems of long lists of parameters

Long lists of parameters negatively affect three desirable properties of software: readability, maintainability, and testability.

Readability

When a function has many parameters, reading its signature or a call to the function requires a lot of mental effort. And, as the number of parameters grows, mental effort increases exponentially.

Any time you need to switch to full-concentration mode to understand individual statements, reading code becomes a pain. Statements should be so straightforward that they glide through your eye. It is only when statements are so trivially simple that reading code becomes a pleasure.

Which of the following statements is easier to understand?

Maintainability

An important problem with function parameters is that, whenever they change, the callers of the function must be updated. This will happen more often as the number of parameters grows larger.

Also, the more parameters a function has, the more information the callers need to know to invoke it. This increases the coupling between the function and its callers.

The higher the number parameters and the tighter the coupling, the bigger the pain to maintain the function.

Testability

To prove that a function works, you would have to write tests for every conceivable input.

For any non-trivial function, this is impossible. You must choose tests wisely.

Choosing tests wisely is easy when a function has 0 or 1 parameters, but it becomes increasing harder with every new parameter because more combinations come into play.

Functions that have many parameters are extremely hard to test.

2. Refactoring towards better design

To reduce the number of parameters of a function, you have several refactoring alternatives:

Create a new data structure

The parameters of a function often share some kind of logical cohesion. If this is the case, and you find that the set of parameters are consistently used together, it may be wise to group them in a new data structure or class.

This has the additional benefit of making the relationship between the parameters more explicit and the code more intent-revealing.

You can also prevent primitive obsession.

Compare:

Join several functions into a class

If you are consistently passing the same parameters to different functions, you can group the functions into a class. The parameters will become data members of this class, and, therefore, the functions will be able to access them directly (without requiring input parameters).

In a similar way to the previous solution (creating a new data structure), this solution applies when the new class represents a useful abstraction that deserves its own name.

Avoid "what-to-do" parameters

A boolean parameter often indicates that a function does two different things: one for true and another one for false.

This can easily be generalized to other parameter types, such as integers and strings.

Regardless of their type, we must avoid "what-to-do" parameters that are passed into a function only to select from outside the internal behavior of the function.

This breaks encapsulation.

When a function has several behaviors, the best thing to do is to split the function into smaller functions that do one thing and have less parameters.

Compare:

Avoid output parameters

The natural interpretation of parameters is as inputs to the function. This is why input parameters are easier to understand than output parameters.

Whenever you are reading code and you wonder whether a parameter is an output parameter, you are breaking your reading flow.

This should be avoided.

If possible, you can reduce the number of parameters of a function by keeping only the inputs. If you need to change the state of something, it can be the state of the object that owns the function.

To end, a short disclaimer …

In our lives in general, and in software development in particular, almost everything depends on context. Long parameter lists are no exception. They are more accepted in some domains than they are in others.

Therefore, it is always good to keep in mind that, every time we invest a non-trivial amount of time refactoring code, we should make sure that we are solving a real problem.

As far as my experience is concerned, I have always found that short lists of parameters make my life easier. This is why I believe that applying the refactoring techniques from this article is often a good investment.

"Design Patterns: Elements of Reusable Object-Oriented Software"

This book is one of the most influential books ever published in the software industry. However, it was written more than 25 years ago. It is reasonable to wonder whether design patterns are as relevant today as they were when the book came out.

Many would answer ‘No’ to this question. A common argument is that design patterns reside at a lower level of abstraction than most developers work on. In other words, design patterns are encapsulated or “hidden” within the frameworks, standard libraries, and languages that developers use today.

I disagree with this argument, and, even if it was true, I would consider it insufficient because the same reasoning applies to, for example, algorithms, data structures, and memory management. We have advanced tools, but this does not mean that it is not important to know what is under the hood.

If, at this point, you have guessed that my answer to the above question is ‘Yes’, you are correct. I do believe that designs patterns are still relevant, and, in this post, I try to explain the reasons behind my opinion.

To explain these reasons, I don’t discuss about what design patterns are. My focus is on benefits of design patterns that I consider relevant for any developer that is working in the software industry in the present time.

1. Design patterns give you design knowledge.

Design patterns represent design solutions that skilled professionals have used again and again in the past to solve recurring problems. Since these solutions incorporate the expertise of qualified professionals, we can expect them to apply good design principles.

Design principles are indeed pervasive in design patterns. For instance, the "State" pattern from the GoF book applies the "Open-Closed Principle" (which is one of the well-known SOLID principles) to make the addition of new states and transitions easier.

This leads to a (probably less conventional) way to look at design patterns: as practical examples that show good design principles in action.

Design patterns is a mainstream technique for organizing design ideas. When you study design patterns, you do not only learn the patterns. You learn design principles and gain general design knowledge.

2. Design patterns give you vocabulary to talk about software design.

Can you imagine an architect discussing about a house only in terms of bricks, walls, doors, and similar “low-level” terms?

It would take ages to describe a basic house.

To keep a more economical discourse, architects use “room patterns” such as bedroom, bathroom, and kitchen. This allows them to convey a lot of information with simple sentences such as "a three-bedroom two-bathroom house". The word “bathroom” carries implied information that does not need to be stated explicitly; for example, strong privacy requirements and specialized infrastructure such as sink and drainage.

In a similar way to construction architects, it would take ages for software engineers to describe a basic system if they could only speak in terms of objects and references between them.

In object-oriented design, everything is an object, a reference or a message. This is a useful abstraction, but you need something more, at a higher level. You need patterns with special names that allow you to convey more information with less words.

You need to be able to say: “add an Abstract Factory to this module” or “we can solve this problem by means of Dependency Injection”.

Design patterns allow you to pack a lot of information in short sentences. Design patterns enable more productive design discussions, when the team is familiar with the patterns.

3. Design patterns give you refactoring targets.

When all you have is a hammer, everything looks like a nail.

It is common, especially when you are learning about design patterns, to apply them everywhere. A pattern can give you an elegant design solution, but it can also add unnecessary complexity. Abstractions have a price, and paying this price is not justified when the abstractions address the wrong problem.

Extreme Programming (XP) advises us to avoid overengineering and to “do the simplest thing that could possibly work”.

If we keep the design simple and the quality of the code high, we can refactor continuously, easily incorporating new abstractions as they prove necessary. During refactoring, we may detect problems that can be solved by applying particular patterns. In this case, the patterns can act as refactoring targets, giving us guidance and direction.

Follow the rules of simple design, avoid overengineering, and refactor continuously. When a pattern solves a real problem, use the pattern as a target. Let it guide you in the refactoring process.

4. Design patterns can improve the readability of your code.

Jack W. Reeves, in his renowned paper from 1992:

“What is software design?”

Suggested that the source code of a software system is the design. He observed that the code is the only entity that, similarly to engineering documents from other disciplines, contains enough information to enable the construction of the actual software product. You can draw diagrams, but they are mere guidelines, ancillary to the actual design.

On the other hand, Eric Evans, in his wonderful book:

“Domain-Driven Design: Tackling Complexity in the Heart of Software”

Taught us the benefits of keeping the source code as a faithful reflection of the domain model. When changes to the code (likely) mean changes to the model and vice versa, the mapping between the two becomes obvious.

These two authors showed us that there exists a tight connection between source code and design.

This has an interesting consequence: when you apply a design pattern, the pattern should be obvious in the code. This will increase the readability of the code, at least for those readers that are familiar with the pattern.

A pattern being obvious in the code does not necessarily mean that the code uses the pattern names. It means that the pattern is easily recognizable.

For example, you can create a method that defines the skeleton of an algorithm and defers some steps to subclasses. Readers that are familiar with Template Method will immediately recognize the pattern, but this does not mean that the method must contain “template method” in its name.

If your code evokes design patterns, the readers that know the patterns will easily understand your intent.

Conclusion

In my opinion, design patterns are as useful nowadays as they have always been, and this post discusses about the four benefits of design patterns that are the reasons behind my belief.

For me, the key observation is that, when you study design patterns, you do not only learn or memorize patterns. You enhance your design vocabulary; you gain general and widely applicable design knowledge; you improve your refactoring strategies; and you enrich the mental toolbox that will allow you to write readable and maintainable code.

These benefits make learning patterns a good investment.

O-notation allows you to characterize the asymptotic efficiency of algorithms. Using O-notation, you can describe how the running time and the required memory of an algorithm increase with the size of the input, as the size of the input grows without bound.

For example, you can say that the worst-case running time of selection sort is O(n²). Informally, this means that the running time of selection sort is bounded from above by a quadratic function of n, where n is the size of the input.

The focus of this post is not on explaining O-notation, however. Here, I assume that you have basic understanding of O-notation and I focus on an aspect of this notation that is arguably less well-known.

Did you know that O-notation is part of a wider family of related notations?

This family is called: the Bachmann-Landau notation.

There are invaluable resources that cover the Bachmann-Landau notation in detail. For example, in these books:

• Introduction to Algorithms (3rd edition). Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford. The MIT Press (2009).

• The Algorithm Design Manual (2nd edition). Skiena, Steven S. Springer (2008).

You will find formal definitions, detailed examples, exercises, and even other notations that I do not cover here.

In this post, I focus on three notations of the Bachmann-Landau family:

• O (Big O)
• Ω (Big Omega)
• ϴ (Big Theta)

My description of these notations is deliberately informal. My goal is just to give you a feel for what these notations are about and why they are useful.

A running example

Through this post, I use Quicksort as an example.

Quicksort is a divide-and-conquer comparison-based sorting algorithm. Even though it has a slow worst-case running time, it is often the best practical choice for sorting because it is remarkably efficient on average.

For this post, let's assume a Quicksort implementation that always takes a quadratic number of steps in the worst-case. And let's also assume that n represents the size of the input, which, in this case, is the size of the input array.

A general view of the Bachmann-Landau notation

In general terms, the asymptotic notations of the Bachmann-Landau family are used to compare functions.

You can express the running time of an algorithm as a function f(n), and, for example, you can say that f(n) = O(g(n)). This means that, for all sufficiently large values of n, the value f(n) is less than or equal to g(n) to within a constant factor.

This comparison-centric point of view is important because the different notations of the Bachmann-Landau family give you the different comparison operators: ≤, ≥ and =.

O-notation

In simple and informal terms:

O-notation gives you a rough notion of less-than-or-equal-to (≤).

In the Quicksort example, you can say the worst-case running time of Quicksort is O(n²).

This means that the worst-case of Quicksort takes at most a quadratic number of steps.

You could also say that the worst-case of Quicksort is O(n³) because O establishes only an upper bound.

If you write that f(n) = O(g(n)), then the function g(n) is an asymptotically upper bound for f(n).

Observe in the figure (taken from the "Introduction to Algorithms" book) that we do not care about small values of n (that is, anything smaller than n₀). After all, we do not care whether an algorithm sorts 5 items faster than another. We care about large values of n.

Observe also that the upper bound is not actually g(n). It is g(n) multiplied by some positive constant c. However, O-notation typically ignores such multiplicative constants.

Ω-notation

While O-notation allows you to express upper bounds, Ω-notation gives you the opposite:

Ω-notation gives you a rough notion of greater-than-or-equal-to (≥).

In the Quicksort example, you can say that the worst-case of Quicksort is Ω(n²).

This means that, in its worst-case, Quicksort takes at least a quadratic number of steps.

You could also say that the worst-case of Quicksort is Ω(n) because Ω establishes only a lower bound.

If you write that f(n) = Ω(g(n)), then the function g(n) is an asymptotically lower bound for f(n).

ϴ-notation

Unlike O and Ω notations:

ϴ-notation gives you a rough notion of equality (=).

For example, you can say that the worst-case of Quicksort is ϴ(n²).

This means that the worst-case of Quicksort takes exactly a quadratic number of steps.

ϴ is a stronger notion than O and Ω because it establishes both an upper and a lower bound.

Therefore, if you write f(n) = ϴ(g(n)), then both f(n) = Ω(g(n)) and f(n) = O(g(n)) hold.

If you write that f(n) = ϴ(g(n)), then the function g(n) is an asymptotically tight bound for f(n).

Conclusion

There are notable exceptions, but it is likely that you will not use Bachmann-Landau notation as part of your daily job. At least, that’s my experience. But, even then, becoming familiar with it (and with the analysis of algorithms in general) is far from useless. Once you get the hang of it, you start considering trade-offs that never existed for you before. You start thinking about what solution is faster for your problem and what implementation is more memory-efficient.

You will start asking yourself: can I do better?

You will still give priority to writing code that is clean and can be maintained easily. But, you will not forget that, after making it work and making it right, you may need to make it fast.

“Clean Code: A Handbook of Agile Software Craftsmanship” (2009)

Ever since this book was published, the term “Clean Code” has become increasingly popular. Today, its meaning is strongly influenced by Uncle Bob's vision, but this does not mean that the term was never used before the book came out.

In my opinion, developers did use the term "Clean Code" before the book was published. And I also believe that developers naturally related the term to code that is easy to read and maintain.

Readability and maintainability are desirable properties of software; however, they do not give us a profound and unambiguous picture of what clean code really is. This is why I want to dig deeper. I want to discuss the essence of clean code beyond its basic properties of readability and maintainability.

If you look at a deeper level, you will see that clean code is subjective. For example, you can consider a fragment of C++ code as unreadable because you are not familiar with the syntax, but experienced C++ programmers may disagree.

Uncle Bob recognizes the subjectivity of clean code in his book:

“There are probably as many definitions as there are programmers“.

This statement sparked my interest in writing this blog post. I want to share what clean code means to me. I want to answer the question “What is the essence of clean code?” even if there are plenty of experts that have already answered the question much better than I will ever do.

1. Clean code reads like a good novel.

When code is clean, you should be able to sit in a comfortable couch, by the fire, with a good drink and dim lights to enjoy the code like you would enjoy your favorite novel.

You might think this is an exaggeration, and you would be right, but to a lesser extent than you may imagine. Reading clean code should definitely be enjoyable, because names are intent-revealing and tell you a story; because the flow is trivial; because statements are so straightforward that they glide through your eye; because the amount of gray cells that you have to engage is comfortably low.

Clean code tells you a story that is captivating and easy to follow.

2. Clean code is simple.

Clean code is so simple that it does not make the author look smart. And yet, it is obvious that the code was written by someone who put effort in it.

Because simple is not easy.

You don’t achieve simplicity on your first try. First, you make the code work, ignoring best practices if necessary. Then, you refactor so that the code is readable and maintainable.

First, you make it work. Then, you make it right ~ Kent Beck.

3. Clean code is tested.

A corollary of the previous section is that you can’t write clean code without refactoring. And, to refactor successfully, you need automated tests to guarantee that behavior does not change. Therefore, you need tests to write clean code.

Furthermore, automated tests are the way code remains clean.

It does not matter how clean the code is today. If it has no tests, you can't refactor confidently. Therefore, the code will become unclean because code tends to get more convoluted and coupled over time.

Refactoring and testing help you counteract this tendency.

The natural tendency of code is not towards cleanness. It is the opposite. Counteracting this tendency requires explicit action.

4. Clean code is focused.

Clean code does one thing and it does it well, in a few words.

The writer does not overload the reader with unnecessary details. The intent is clear. There are no ambiguities. It doesn't have surprises and unintended side effects.

If you call "isPrinterReady”, you know the function will only check if the printer is ready. It will not inadvertently remove a file.

Clean code does what it says, without unexpected twists.

5. Clean code does not repeat itself.

Clean code says everything once.

This does not mean that duplication is eliminated blindly. Clean code avoids premature abstractions and it knows that, if two identical pieces of code represent different knowledge, removing duplication introduces risk.

Clean code follows the DRY principle, but it acknowledges that DRY is about knowledge duplication, not code.

6. Clean code speaks about the problem, not the solution.

If a name in your code includes a “computerish” term (such as “DTO”), it is probably focusing on “how”.

Clean code focuses on “what”.

Clean code uses terms that focus on the problem domain, not on the specific solution on a computer.

And these terms are at the right level of abstraction. If a software module is in the domain layer, the code will use terms of the domain model. If a module is in the database layer, it will speak about databases.

Clean code uses the right level of abstraction to talk about the problem being solved.

7. Clean code pays close attention to details.

When you write clean code, you get details right and you do not make arbitrary decisions. If you declare a protected field, you know why you don't declare it private. If you declare a dynamic array, you know why a static array would not be better. Every detail counts.

In clean code, error codes and exceptions are meaningful; error handling is explicit; names are consistent; there are no memory leaks; etc.

In software development, details matter. Clean code recognizes this truth.

8. Clean code does not smell.

When you see code that smells bad, it is probably wise to refactor because design smells are often symptoms of deep quality problems.

Clean code does not smell, or, if it does, the odor is weak.

• Clean code is not rigid. It is easy to change.
• Clean code is not immobile. You can reuse it easily.
• Clean code is not opaque. The intent is easy to understand.
• Clean code is not fragile. You can change it without introducing errors.

If it stinks, change it ~ Kent Beck.

Conclusion

After (hopefully) getting a deeper understanding of what clean code is, you may be wondering: why would I want to write clean code?

The main reason for me is that code is read far more times than it is written. Therefore, it is inefficient to favor solutions that make writing fast at the expense of making reading slow.

For example, it may be tempting to add a method to an interface only because you need to call the method and you hold a reference to the interface, but this can make the interface less cohesive and harder to understand.

Always consider the consequences of your actions. Do not take steps back in your journey towards clean code.

The only way to go fast is to go well ~ Uncle Bob.

My humble advice for software companies:

Stop looking for experts in paint brushes and focus your efforts on finding good artists. Focus your efforts on finding software engineers that can write clean code. This is how you go fast and at a sustainable pace. You must pay attention to technical excellence if you want to be agile. You can't be agile if you write dirty code.

However, after all of these years of practice, I have learned some benefits that were less obvious to me when I started.

In this post, I share them.

Maybe, when you read this post, you think that these benefits are basic and well-known. That’s fair. My claim is just that they were not obvious to me when I was writing my first automated tests.

My lack of awareness at that time is the main motivation behind this post. If I can make only one person discover these benefits quicker than I did, then my goal will have been achieved. If I can convince only one unconvinced person of the usefulness of testing, then this post will have gone far beyond my initial expectations.

1. Tests give you code samples.

Have you ever skipped an answer in StackOverflow because it didn't contain a code sample?

We look for code samples because they help us understand how things work.

Automated tests play the role of code samples. Each test represents an example of how the system is used at the code level; therefore, they are of invaluable help when we are trying to understand the system better.

A software system is easier to understand if it has automated tests in place.

2. Tests give you executable specifications.

Written documents become obsolete easily, so they often lie. They specify what the system is supposed to do, not what it really does.

The only truth about the system behavior is in the source code. The code brings this behavior to life and makes it possible; the tests specify, document, and enforce it, in a formal and unambiguous way. Therefore, automated tests are executable specifications of the behavior of the system. If this behavior changes, the tests will fail. If we want to change this behavior, we must adapt the tests.

Tests specify how the system actually behaves and they are always up to date.

3. Tests give you the first users of your code.

When you are writing tests, you become a user of your own code. If the code is bad, you are the first to experience the problem. This makes you put more effort in refactoring, and in writing clean code and clean tests.

When you want your tests to be clean, you will choose better names for your variables, functions and classes. This improves the readability of your tests, which, in turn, improves the readability and design of your code, which, in turn, makes testing easier. It is a self-reinforcing loop.

A good testing strategy leads to cleaner code.

4. Tests give you immediate feedback about code changes.

Have you ever felt the pleasure of misspelling a variable name and getting immediate feedback from your IDE?

Your IDE warns you about this kind of errors because they are syntactic issues that can be detected via static analysis at compile time. But, you can get the same kind of feedback about runtime errors. You only need fast tests that you can run after every change in your code.

For example, if you replace “+” with “-” by mistake, you will change the semantics of the code and therefore its runtime behavior. If the tests are semantically stable, they will detect the error immediately.

Automated tests shorten the feedback loop on coding decisions.

5. Tests prevent the occurrence of bugs.

Having quick feedback on coding decisions has a significant consequence: bug prevention.

Tests specify the behavior of the system. As long as the tests are there, this behavior is preserved. If, sometime in the future, you change this behavior unintentionally, the tests will catch the error. This error, which might have been detected months later, has a lifetime of less than a few seconds.

Tests help you detect errors early, when they are cheapest to fix.

6. Tests give you a safety net.

With a good suite of tests in place, you can modify code, run the tests, and immediately know whether you altered the system behavior. In other words, you can modify code safely.

This is where the safety net metaphor comes from. Automated tests act as a safety net that allows us to refactor confidently, in a similar way to trapeze artists to perform without fear of being hurt. But, nets can contain holes through which we may fall. These holes take the form of untested behaviors, where potential bugs may hide.

Automated tests protect us from unexpected, and potentially harmful, events. But, test suites must be comprehensive, if we want them to meet this goal effectively.

7. Tests have positive architectural implications.

To test a unit of code properly, we must isolate it from its dependencies. This is typically accomplished through the use of test doubles, also known as mocks.

When the code is highly coupled and dependencies are hard-coded, isolation becomes difficult and testing sometimes prohibitive. This implies that, the more loosely coupled a system is, the more of it can be verified in terms of unit tests. In other words, the lower the coupling, the higher the testability.

Automated tests lead to low coupling and higher-quality design.

Conclusion

If we consider all of these benefits together, we can reach an important conclusion:

Automated testing dramatically increases software quality.

And high quality is the only way we can have:

• Ability of respond to change quickly.
• Huge savings in time and money.
• High customer satisfaction.
• A motivated development team.

In this new era of uncertainty that we are currently living, all of these advantages may be more necessary than ever before.