In an effort to reduce rework and its associated costs, many software teams have implemented test-driven development (TDD). The rationale: The earlier you catch a problem in the software development lifecycle (SDLC), the less expensive it is to fix.

The premise of TDD: You write the test before you write the code

With TDD, testing is at the forefront of people’s minds during product architecture, design and development. Software developers define upfront what and how to test. To be considered complete, what does the feature (code) need to be able to do successfully? What tests need to pass for the code to be called good?

Developers write these tests one at a time, starting with an easy case and building complexity from there, before coding the feature. This enables developers to make sure every possible scenario is covered. The feature must pass both the old and new tests before a developer commits it to the code base.

How does TDD differ from earlier development approaches?

Before TDD, developers wrote code and QA wrote tests. These functions were silos. Even within a single team, developers used varied criteria to decide when to commit code to the base. Some developers felt testing was 100 percent QA’s job. Others wanted to make sure their code worked before sending it to QA. The individual developer decided how much testing to do (or not).

This led to inconsistent quality levels coming out of development, resulting in considerable rework, which impacted schedules and budgets.

What are the benefits of adopting TDD?

TDD is less expensive than the siloed approach. Here’s why: When developers add new code to the base, the code works and doesn’t break the base.

The TDD mantra, “Keep it green,” means the test result is always green before submitting code to the base (where it impacts others). If it’s not green, the developer keeps working on the code while it’s top-of-mind until it passes the test.

The silo approach where developers toss code over the wall to QA means that coders have already moved on to new functionality when QA finds bugs. The delay in finding the bugs can have downstream consequences. Anything built later that relies on the problematic code may also need rework.

Another benefit: Tests document the code. When you read a test, you understand what the code should be doing, so you can validate that it’s working correctly.

Are there any downsides?

Some managers perceive that TDD takes longer, and they worry about how that will affect schedules for shipping new functionality.

Yes, it’s true that TDD requires extra time when building features. Software developers now have additional code (tests) to write and maintain. However, executives benefit from taking the long view. By spending a little more time on the front end of the SDLC, it’s possible to shorten the full SDLC significantly. Additionally, TDD improves the quality of software releases, which can lead to higher customer satisfaction and more revenue.

Another downside: Complex product development efforts may require writing additional proprietary frameworks to test how the product interacts with third-party tools, utilities and so forth. If you have a utility that you’ve customized in a specific way, for example, you need to create tests to make sure your product uses the utility correctly.

Common barriers to TDD adoption

The biggest barriers to adoption are engineering culture, individual developers’ preferences and the pressure to get products to market quickly.

In some organizations, TDD requires a significant shift in mindset. A change management expert can take the “temperature” of an engineering team to identify openness to TDD, areas of resistance, concerns and so forth. Sometimes, senior developers will say, “Testing is not my job. My super power is creating new stuff, and I don’t want to be slowed down by writing tests.”

Some managers balk at TDD, feeling it will slow their team’s velocity. They want a high-quality, robust product but sometimes are willing to take shortcuts to get a release out the door.

To implement TDD successfully, management cannot allow elitist and speed-at-all-costs attitudes to persist. Engineering leaders need to set the expectation that all developers—even architects—are responsible for testing and code quality. If the architect is writing production code, then the architect is writing tests. Training can help get all team members on the same page and establish the testing ground rules everyone must follow.

Some organizations also wonder how to implement TDD on legacy projects. In this situation, start with the new features. And then, when refactoring portions of the legacy code, add tests for the newly refactored segments.

What mistakes do organizations make when implementing TDD?

There are three common errors that leaders can prevent with the right planning and communication:

1. Writing sloppy test code: Software developers need to treat test code and test utilities as production-level code. The test is going to live as long as the production code, so it needs to be well-written. Taking shortcuts can come back to bite you in the future.
2. Relegating testing to junior staff members: Many organizations put newer engineers on testing and senior people on production. In TDD, the testing is as important as the coding and needs oversight by experienced developers who can spot problems quickly. As a code base grows and becomes more complex, you want someone who knows what to look for and how to organize code. New-to-career programmers don’t have the experience to do this effectively, and you can end up with a mess.
3. Allowing broken tests to stay broken: Look up The Pragmatic Programmer or read Malcolm Gladwell’s book, The Tipping Point. Both offer examples of how ignoring something bad can cascade into a bigger problem. Some teams allow tests to break and then leave them broken, sprint after sprint. The damage from this approach compounds over time, and the longer you allow this to continue, the more expensive and time consuming it is to fix.

TDD solves a human limitation

Airline pilots use preflight checklists to eliminate the possibility of overlooking or forgetting something important. TDD serves a similar purpose.

Before TDD, a developer might have tested code manually, determined it passed and submitted it to the code base. But often, there was some interaction that the developer didn’t think to test for. So, submitting the code broke the base or caused other features not to work properly.

Lines of code execute based on different situations. It doesn’t take long to reach the point where developers can’t keep in their heads all the code and all the scenarios the code is supposed to handle. If multiple people on a team are contributing to the code base, no individual can track all the ways the software interacts.

TDD runs all the tests, old and new, on any new code. Some tests have interactions with the new code; others don’t. But developers do not have to keep this information in their heads, which reduces human errors and oversights. TDD frees developers’ working memory for other important problem-solving activities.

If a test is green, developers know their code works correctly and hasn’t broken anything. These tests confirm both the old and new functionality work properly.

For more information on TDD and virtual instructor-led courses on testing, email [email protected].

Image credits: istock.com/Eisenlohr and istock.com/jojoo64

We’ve all met code hoarders and “heroes.” Like basketball players who hog the ball, hoarders work alone, reluctant to share their code, while heroes jump in at the last minute to fix other people’s code. These software developers think they’re helping, but their actions damage morale, slow down team development and limit innovation.

Pluralsight developer advocate Jeremy Morgan explored these behaviors in a recent podcast with DevelopIntelligence CEO Kelby Zorgdrager. Here are three takeaways from their conversation on how code hoarders and heroes impact teams—and how to resolve those conflicts:

1. “Heroes” might save the day in the short-term, but at a long-term cost

A software developer who dives in at the 11th hour to fix other people’s work may get credit for helping a team meet an important deadline. But swooping in like this on a regular basis has a dark side, worse than backseat driving. When “someone comes in, pushes you aside, takes over your keyboard and says, ‘Let me fix this for you…let me make it better,’ as Zorgdrager said, it can create trust issues for the team.” As a developer, you don’t really want to give up your keyboard. It’s like the steering wheel for your car.”

For the person receiving this “help,” heroing creates self-doubt. As Zorgdrager explained, it causes developers to ask themselves, “Do I really suck at writing code? Or did I not understand the problem that I’m supposed to be working on?”

As Morgan pointed out, the “hero” might feel good about his or her contribution, but other team members experience an incremental erosion of confidence.

“You know how confidence builds slowly and then starts growing like a snowball?” Morgan said. “Unfortunately, the process works the same way in reverse.”

2. Code hoarders prevent others from learning and growing

Morgan described hoarders this way: “Someone starts saying, ‘This is my code; this is my section; this is my class method; or even this is my whole entire project. Don’t touch it.”

Why is this problematic? Zorgdrager offered two vivid examples from his own career of how this dynamic plays out. At a startup where he served as interim CTO, the founder and CEO had written a fair amount of the code. “Our CEO still wanted to write code, as well as control and dictate the direction of the architecture and code we were building.”

“In the first six months, we probably lost half of our engineering team,” said Zorgdrager. “The founder wouldn’t get his fingers out of the cookie jar. It was a very negative experience.”

The second company, a telecommunications giant, had engineers who had been there 30 years and weren’t interested in sharing code with new hires. “This was frustrating,” he recalled, “because as a younger person working in the tech field, you want to create something cool. The more senior engineers didn’t want to share the ‘secret sauce,’ limiting innovation.”

3. Both code hoarders and heroes need to understand their effect on others

Because these behaviors damage team development and morale, coworkers and managers need to speak up. Instead of saying, “Jeremy, quit hoarding your code,” Zorgdrager recommends focusing on how the behavior affects team members. How does it make people feel? What’s the impact on others’ ability to do their jobs? “This approach leads to a more productive conversation than saying, ‘Hey, you shouldn’t do this.’”

Ideally, a meeting like this would happen face-to-face. With so many people working from home due to COVID restrictions, however, this may not be feasible.

“In the remote environment, we too often use Slack or email for a conversation that should be in-person or over the phone,” said Zorgdrager. If the topic is sensitive, with a potential for conflict, misunderstanding or hard feelings, you ideally want to be able to see body language. Without this, you are missing an important component of the dialogue.

Zoom isn’t perfect, but a private Zoom meeting is certainly better than making snarky comments in public Slack channels.

Code hoarders and heroes are two of the profiles described in the free e-book 20 patterns to watch for in your engineering team. Check it out and take an honest look at your engineers. Are certain well-intentioned behaviors sabotaging your digital transformation efforts?

Image credit: istock.com/gorodenkoff