The Deployment Pipeline is a critical tool for ensuring software quality – and quality is a prerequisite for speed.

So, what is a Deployment Pipeline? How has it helped us improve both quality and speed? And what are, in my experience, the common problems in using and implementing deployment pipelines?

A Deployment Pipeline is a machine that helps us move from an idea to valuable software in the hands of users by organizing software development work. It enables us to go from commit to releasable outcome as quickly and efficiently as possible, in a repeatable and reliable way.

— Dave Farley, Continuous Delivery Pipelines: How to Build Better Software Faster

Before exploring how Deployment Pipelines have helped us, it is helpful to briefly introduce Continuous Integration and Continuous Delivery.

Continuous Integration

Continuous Integration is a software development practice that helps us create and maintain a high-quality codebase that is easy to change and to implement new features.

As Martin Fowler points out, the practices of Continuous Integration are:

• Put everything in a version controlled mainline​
• Automate the Build​
• Make the Build Self-Testing​
• Everyone Pushes Commits To the Mainline Every Day​
• Every Push to Mainline Should Trigger a Build​
• Fix Broken Builds Immediately​
• Keep the Build Fast​
• Hide Work-in-Progress​
• Test in a Clone of the Production Environment​
• Everyone can see what’s happening​
• Automate Deployment​

Kent Beck developed the practice of Continuous Integration as part of Extreme Programming in the 1990s. The book Continuous Integration by Paul M. Duvall, Steve Matyas, and Andrew Glover was published in 2007. While this is nothing new, many software engineers and teams still do not practice Continuous Integration and therefore miss out on the benefits it provides.

Continuous Delivery

Continuous Delivery can further help create and maintain high-quality software. The excellent book Continuous Delivery by Jez Humble and David Farley was published in 2010. and it describes the idea behind continuous delivery in detail, and it introduces “…the central paradigm of the book – a pattern we call the deployment pipeline“.

Continuous Delivery is the ability to get changes of all types – including new features, configuration changes, bug fixes and experiments – into production, or into the hands of users, safely and quickly in a sustainable way.

– https://continuousdelivery.com/

Continuous Integration is a prerequisite for Continuous Delivery.

The minimum activities required for Continuous Delivery, as defined by minimumcd.org, are:

• Use Continuous Integration​
• The application pipeline is the only way to deploy to any environment​
• The pipeline decides the releasability of changes, its verdict is definitive​
• Artifacts created by the pipeline always meet the organization’s definition of deployable​
• Immutable artifact (no human changes after commit)​
• All feature work stops when the pipeline is red​
• Production-like test environment​
• Rollback on-demand​
• Application configuration deploys with artifact​

Deployment Pipeline

The best description of deployment pipelines, and practical advice on how to implement them, I found in another excellent book Continuous Delivery Pipelines, How to Build Better Software Faster by Dave Farley. According to him, automation is the key… and is the engine that drives an effective Deployment Pipeline:

• Test Automation​​
• Build and Deployment Automation​​
• Automate Data Migration​​
• Automate Monitoring and Reporting​​
• Infrastructure Automation​

The simplest deployment pipeline should, after each commit, compile the code (if needed), run all unit tests, create a deployable artifact, execute acceptance tests, and enable deployment to production.

However, a deployment pipeline can do much more, such as:

• Static code analysis
• Enable manual testing
• Performance tests (e.g., latency, throughput, load)
• Data and data migration tests
• Security tests
• Reliability tests etc.

CI practices

I see many teams/companies have a Jenkins job that compiles source code, runs (a few) unit tests, creates an artifact – often a Docker image – and have a separate deploy job/button to deploy to the dev and production environments. And they will say they are “using” CI/CD. But most of them are skipping some of the CI practices and don’t have code in an always-deployable state, even as a goal, yet still think they are “using” CI/CD.

CI practices are not a menu where you can choose what you like and still have all the benefits CI can help you with.

Make the build self-testing

Test-Driven Development (TDD), or test-first development, is still an exception, and developers usually write tests after the code. Those tests are mostly unit tests (developer-oriented) and much fewer acceptance tests (user-oriented) that cover only parts of the functionalities. The test-after approach usually covers less functionality because the code is harder to test, and tests are complex to write and maintain. Such tests don’t provide fast and good-enough feedback to automate “releasability of changes” or “enable refactoring for sustained productivity.” Developers don’t trust such tests, so manual verification and team coordination are needed to decide when code can be deployed, which is never fully reliable, and more bugs reach production.

Everyone pushes commits to the mainline every day

Same as TDD, trunk-based development is still an exception, and almost everyone is using branches and pull requests with many PR reviews at the end of the sprint, so they are not practicing continuous integration by definition. They are missing the benefits CI brings, like “less time wasted in integration” and “enables refactoring for sustained productivity.”

Test in a clone of the production environment​

Some companies have a “static” copy of production, with test data already prepared in a database, where they deploy their applications and run tests. As a result, developers can’t run tests on their laptops, test preparation is complex and slow, and they regularly break other tests. Feature flags can’t be tested, and it takes a long time from commit to getting test feedback. This demotivates developers from writing tests, and over time, this negative spiral creates ‘legacy’ code that is hard to change.

Rarely does any company I know create, on demand, a “clone of production” – with the configuration needed for a suite of tests set up exactly as in production, where the tested application is deployed the same way as in production and then tested to determine the releasability of changes.

Usually, a Jenkins job starts the needed testcontainers during the integration test phase and tests parts of the application – or a “test” version of the application – that differ from the production application. These tests don’t cover the application artifact that will actually be deployed, nor do they test deployment, configuration, or dependencies (e.g., microservices) that aren’t properly mocked. Instead, some fake repository or adapter implementations are used that don’t exist in production.

The application pipeline is the only way to deploy to any environment AND The pipeline decides the releasability of changes; its verdict is definitive​

From what I’ve seen or heard, everyone has a workaround that allows deployment of artifacts that didn’t pass the Deployment Pipeline. Sometimes they create artifacts on their laptop and push them to the repository so they can be deployed. Other times, the pipeline itself allows deployment of code that hasn’t passed all required verifications.

This can happen when a “non-important” or “flaky” test fails, or when a dependency has a critical vulnerability, etc. Usually, the team says these problems will be fixed later, when there’s time, but the new feature is considered urgent and must be deployed ASAP. In practice, the team never has time to fix these issues, workarounds become the norm, and the deployment pipeline turns into a theater.

Keep the build fast

With microservices being so popular, build time shouldn’t be a major problem. Yet it’s common to see builds lasting half an hour or more.

In my experience (mostly with Java), if you create tests – unit tests, acceptance tests, etc. – that can run in parallel, it’s easy to have a deployment pipeline finish in under 5 minutes, excluding deployment. Just run everything in parallel: unit tests, acceptance tests, services with different feature flags enabled or disabled, and static code analysis.

A Deployment Pipeline must be built, not bought

A deployment pipeline automates your software development process and reveals both its strengths and weaknesses. When your practices are strong, the pipeline amplifies them, providing significant benefits. Conversely, if your practices are weak, the pipeline makes this very apparent – it can be difficult or even impossible to implement effectively.

This is why Continuous Integration and Continuous Delivery are so valuable: they encourage good practices and make problems visible early. A Deployment Pipeline is not a product you can buy or outsource; you must build it yourself, leveraging various tools.

In my experience, the best way to achieve both speed and quality in software development is to combine pair or mob programming with test-driven, trunk-based development, supported by a deployment pipeline that automates feedback on key aspects of the process. This approach provides rapid feedback, within minutes, on ideas and experiments through frequent commits and accompanying tests. It allows the codebase to evolve continuously through refactoring and enables the frequent, low-risk release of new features with minimal stress.

The post What It Takes to Fully Benefit from a Deployment Pipeline appeared first on ShiftMag.

I often see code with readability and maintainability issues caused by primitive obsessions and premature generalizations. Both problems have been well-known for a long time, well-described, easy to understand, and easy to avoid.

The key is to use domain-specific types and generalizations thoughtfully, applying them only when they genuinely simplify the current requirements. Doing so makes your code not just cleaner, but also much easier to read and maintain.

How do we avoid primitive obsession?

Primitive obsession occurs when a software engineer uses built-in primitives and classes instead of custom, domain-specific types. This problem is described in many presentations, blogs, or books, such as in Chapter 65, “Prefer Domain-Specific Types to Primitive Types, by Einar Landrein thebook 97 Things Every Programmer Should Know.

The most commonly used types in Java applications, from my experience, are String, int, and List, where String creates the most problems. These types, along with other primitives and built-in classes, are certainly needed, but they should primarily be used as implementation details, not as domain-specific types.

For example, when an int is used to represent a package weight, it’s not clear which unit of measurement is being used – grams, kilograms, tons, pounds, or what the accepted values are. 

Similarly, when a String is used for a color, it’s not clear what values are supported – an RGB hex value, CMYK, “red”, “yellow”, “black”, some locale-specific values, etc. Joshua Bloch describes the problems with String overuse in Item 62: Avoid strings where other types are more appropriate in the Effective Java, Third Edition.

Lists are often used as a simple collection of Objects, and all related business rules are scattered throughout the application. A common problem is that a List can be updated anywhere without any business rules. And that’s just a sample of the readability and maintainability issues when using primitives.

When domain-specific classes are used:

• Semantics become clearer because we are thinking in domain-related terms, not Strings or ints.
• All business rules have an obvious place for implementation – the domain-specific classes. Code and idea duplication can be avoided.
• Only allowed functionality and methods are exposed to users, making the API easier to understand and use.
• Implementation details can be hidden from users, making the code less coupled and easier to change.
• Methods are easier to understand, and the compiler will help with using correct arguments – e.g., there are no more methods with many Strings and ints as arguments where it’s easy to replace the order – someMethod(String a, String b, String c, int x, int y, int z)

Don’t create a general solution for a specific problem

Premature generalization happens when we implement generalizations in a code for possible and unclear features that are not required for current and known tasks. Dan North explained that in an excellent blog, “Best Simple System for Now“.

Most of us are working on applications that need to solve some specific problem. So, we should implement only those particular features that we understand well enough to implement. Too often, I see code that has (half-)support for enabling future and unknown features, which makes implementation much more complex than needed for the initial and specific requirements. Those future features are always different from what is expected or are never required and won’t be implemented. 

However, some additional features will be required to implement, and their implementation will be more complex due to unnecessary generalization.

Therefore, the next step should be the removal of unnecessary generalization before introducing the new feature; however, often, a new feature is added to the code with unnecessary generalization. The tech debt is growing, and future development is becoming increasingly complex.

I’ll share my “secret” with you

In my experience, the best way to implement features is to use Test-Driven Development (TDD) and Behavior-Driven Development (BDD) to stay focused on the essential requirements.

When working on applications, if generalization is needed to support new features, we can typically achieve it using the refactoring tools provided by modern IDEs. Since we’re guided by explicit requirements, any generalizations we introduce are purposeful and aligned with actual user needs.

To sum up: primitive obsession and premature generalization are common pitfalls, but they are easily avoided. Using clear, domain-specific types and delaying generalization until it’s truly needed keeps your code readable and maintainable. By focusing on actual requirements and leveraging TDD and BDD, you build simpler, cleaner solutions – no more ancient hieroglyphics, just clear, understandable code.

The post This is how two simple changes can improve your code’s maintainability appeared first on ShiftMag.

No one says, “This code is a “big ball of mud,” but adding new features is quick and easy.”

But still, too often, I see developers attempt to be faster by skipping refactorings, tests, and other practices that help create good-quality code. They just start adding new lines, but the change soon becomes too complex. Since they are developers, they will make it work in the end.

Sometimes, they may be even faster making that one change. However, the design will be harder to understand, implementation complexity will be higher (high coupling, low cohesion, etc.), and testability will be lower, making every following change harder and slower.

After a few times cutting corners like this, the code will become too complex to understand, and every subsequent change, no matter how little, will be risky.

The snowball effect of (losing) quality

Even worse, when the next developer needs to work on a new feature in that codebase, it will be easier to continue working with little attention to quality because it’s evident in the codebase that quality is not a priority (I think it would be evident that development speed is also not a priority).

With such a cycle, in a relatively short time, any codebase can become complex, risky, and expensive to change.

There is also a problem with what software quality means and how to measure it. I like the quote from “2022 Accelerate State of DevOps Report“:

The ease with which an organization can safely and confidently change its software is a marker of the software’s quality.

David Farley

Creating quality software takes time, usually more than taking shortcuts during development, but it will enable future changes and speed. And it’s not always easy, as Kent Beck warns us: “For each desired change, make the change easy (warning: this may be hard), then make the easy change”

Might be interesting to note that Beck gives a lot of practical advice and guides on when and how to improve your code in his excellent book: “Tidy First?” – and there are many other books on creating quality code and software.

Quality is the prerequisite for speed

There is no lack of people building on the myth that there is a trade-off between quality and speed. It’s just the opposite: quality leads to speed.

In his video “How To Build Quality Software Fast“, Dave Farley explains why there is “No Trade-Off Between Speed & Quality”, noting that cutting corners leads to slower, not faster, development.

Adam Tornhill shows data that confirm how a good-quality codebase improves development speed in his presentation “The Code Quality Advantage: How Empirical Data Shatters the Speed vs. Quality Myth“. He also shows when to invest in better quality and when it may not be needed (for example, in codebases that are rarely changed).

Even the State of DevOps reports that “teams who score well on speed consistently score well on quality” – and they report that every year.

Hurry… in small steps

In my experience, the best way to achieve both speed and quality in software development is to do pair programming using test-driven and trunk-based development with a great deployment pipeline. 

That combination makes you work in small (tiny) steps and ensures fast feedback from your programming partner, tests, and deployment pipeline – meaning you’ll quickly correct and adapt to any design and coding error.  By breaking up complex problems into smaller and simpler ones, we can implement them faster because we are working in small steps that are easy to understand, implement, and verify.

What is your experience with speed and software quality? Is there a trade-off? Please share your experience with me on Twitter or LinkedIn! 

MORE READING:

The post The dilemma of quality versus speed is false appeared first on ShiftMag.

I’ve always liked the idea of test-driven development, and it’s three simple steps – write a test, make it pass, and refactor – but it took some time before I could say that TDD really works (for me).

I first heard about it over 20 years ago, probably when somebody talked about Kent Beck’s Extreme Programming:

In XP, when possible, tests are written in advance of implementation.

If I am programming test-first, I write one failing test, make it work, and then write the next failing test.

In Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce further define it as follows:

The cycle at the heart of TDD is: write a test; write some code to get it working; refactor the code to be as simple an implementation of the tested features as possible. Repeat.

Using TDD should result in significantly fewer production bugs by having code that works as expected (in tests) and with better design and higher quality of the code (“easier to change”). The code should be modular, loosely coupled, cohesive, separate concerns well, and provide good encapsulation.

Dave Farley made it almost a haiku:

The goal of TDD is:

Well Designed Code,

That We Know Works!

A luke-warm introduction to TDD

Initially, I listened to and learned about TDD through conference sessions, online tutorials, and books, as well as trying it out in my (test) projects. I always got the “green bar,” but I didn’t think my code was significantly better than before, with tests written after the code.

One notable difference was that the code was testable (or at least more testable than before). But I didn’t see all the benefits I’ve read about.

Nevertheless, many authors, presenters, and software engineers I liked and learned other things from, and whose frameworks and libraries I used, kept talking about TDD and the many benefits they reaped from it.

So I kept at it, but every time, it didn’t feel like I was doing it correctly, and I definitely didn’t think I got the “advertised” results.

My mistake: Taking too big of a bite

Later, I started working on complex information systems, implementing complex business rules with a relatively small and stable team, where the developers were domain experts.

The ever-growing and ever-changing business rules made me more appreciative of a codebase that was easy to change, but that too often wasn’t the case with (my) code. At the time, we were writing some unit tests, more functional tests (actual use-case tests), and doing a decent continuous integration on most applications.

I refactored code daily to make it more readable and understandable. I mostly used rename/extract variable/method/class, and the code was better each time, but again, it wasn’t as easy to change as I would have liked it. The problem was that my object design wasn’t the best, and I tried to find a way to improve it. I also often tested implementation instead of functionality.

What helped bring me closer to TDD and up my object design Domain-Driven Design (DDD). For me, the largest breakthrough came from internalizing the concepts of bounded contexts and ubiquitous language, but Entities, Value Objects, and Service Objects, including Aggregates, helped me with object design. 

When I was writing code (in Java), influenced by DDD, the code was usually easier to understand, but the tests I wrote after the code were too hard to write and maintain. So, again, I tried TDD. Once again, my code was better, not to the full extent TDD enthusiasts raved about.

I later understood that my biggest mistake was that I wasn’t working in small steps, starting with the simplest (“boring”) use cases and building up to the more complex ones. The other mistake was that I didn’t refactor the code to “Well Designed Code,” so the methods and classes were too complex and coupled. The tests were simply too complex to set up and maintain.

And I’m not the only one who made that mistake, according to Dave Farley:

Over-complicating the solution is one of the commonest mistakes that I see TDD beginners make. They try to capture too much in one step. They prefer to have fewer more complex tests than many, small, simple tests that prod and probe at the behaviour of their system. The small steps, in thinking and in code, help a lot. Don’t be afraid of many small simple tests.

Go TDD or go home

In the end, the circumstances pushed me all the way to TDD. I found myself in a situation where I had to maintain and further develop an application that processed billions of messages daily, had only a few tests, and had no access to developers who initially built it. It had complex and large classes and methods, scalability and reliability issues, and high hardware demands.

The only way to survive that was implementing much better code than I was doing before.

So, once again, I turned to books, videos, and courses about TDD, refactoring, creating APIs, and code quality to improve my object design and its implementation.

This time, I implemented many (small?) changes in my designing and coding way of doing TDD:

1. Working in small, really small, steps with a commit after each step (many 10s per day)
2. Stopping the primitive obsession
3. Refactoring until the API design is good (“You are the first user of the API”) and tests are easy to write, understand, and maintain (“Tests are trying to tell you something”)
4. Doing pair programming

I noticed significant changes in my code in a few months. It was simpler to understand, and the methods and classes were much shorter (but there were more classes). Adding new features wasn’t a challenge anymore, and other developers could help me in hours or, later, in minutes, without lengthy onboarding.

With Golden Master tests and using TDD for new or changed and refactored code, soon there were enough tests and, as a result, confidence that changes to the code won’t carry any significant risk.

In that short time, using TDD daily, I got very predictive and almost constant progress in the right direction with my coding, and I could provide value to my users better and faster. 

It wasn’t TDD; it was me

In retrospect, I think that my problem with getting better code with TDD was in my design and coding skills, not in TDD. Not that they were particularly bad – I did manage to create and maintain large, complex, and successful applications/systems.

But I missed some (or many?) details that make TDD something people rave about. If you have the chance, find someone good at TDD and pair program with them for a few days to see if it works for you.

What was your turning point in using TDD and getting good results? Please share your experience with me on Twitter or LinkedIn! 

The post How I failed at Test-Driven Development and what it took to get it right appeared first on ShiftMag.

The team comprises developers with different backgrounds and levels of experience. The idea was to use pair programming to level the team and make everyone faster and more independent in developing new features. We already had positive experiences with pair/mob sessions when troubleshooting production problems or supporting our users (other engineers and support teams), so we gave it a go. 

We’ve been at it for two years and are happily reaping the benefits.  

What is pair programming? 

Even though programming in a pair has been practiced since the dawn of programming, the practice was first introduced to a broader audience in the 90s. In his excellent book “Extreme Programming Explained” from 1999., Kent Beck defined pair programming as follows: 

All production code is written with two people looking at one machine, with one keyboard and one mouse. […]There are two roles in each pair. One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically...

Kent Beck, Extreme Programming Explained, 1999

Today, there are more options for pair programming than sitting together in front of a computer with one keyboard and mouse, from simple screen sharing to specialized tools like Code With Me from JetBrains. However, the above-mentioned principle remains the same. 

I heard about pair programming long ago and was always intrigued by it, but I hadn’t had practical experience before we introduced it two years ago. I heard a lot of positive experiences with it, and the success stories were impressive. 

There is also a fair amount of skepticism, whereas the main concerns are that pair programming is expensive, slow, and necessarily ends in frustration – everything you would like to avoid in a team. And diametrically opposed to what we were trying to achieve. 

Rocky start, stellar results 

As the team was already collaborative and had a proven record of great teamwork, we weren’t afraid of pair programming ending in infighting. And yet, we were off to a rocky start. 

Although everyone was theoretically up for trying pair programming, we didn’t want to make it mandatory. This meant that, in reality, people were quite shy about asking for pair programming. 

One of the issues was that they often didn’t deem a feature valuable or complex enough to have two developers working on it, or there was pressure to code a feature as fast as possible – and talking about it all day long seemed like a waste of valuable time. There were also some social fears: What if other team members saw everything I don’t know, what I have to Google, how slow I am?  

We gave up on pair programming on routine, repetitive, and simple tasks because we didn’t get any added value. In that case, pair programming did prove too expensive. But, when adding new features, we saw more and more benefits. 

It also took us some time to figure out how to be productive without frustrating each other with unhelpful comments and remarks. We found ways to work through things that bothered us (talking to team members can solve almost anything, right?). We took a pause when needed or moved programming sessions to different times. We didn’t use any specific tool for pair programming, just screen share and audio call. 

Despite our hesitations, even the first pair programming sessions were a positive experience – mainly because we all learned more than we expected not only about programming, frameworks, or tools we used but also about the domain and the feature/problem we need to solve.  

We noticed that the ratio between talking and coding was much higher than we expected. Since we better understood the problem, the developed solutions and code were better than they would have been if we were coding alone. 

Better readability, predictability, and quality 

In the beginning, the most experienced team member was the driver of most sessions, and we rarely switched roles during sessions. Still, we were noticeably more productive than working alone.  

We paired for 3-4 hours a day, as we had other operations and support we needed to attend to. Not to mention that pair programming requires complete focus and can be exhausting, so 3-4 hours per day was the maximum anyway. 

Focus was strictly on the task at hand, without the usual interruptions (Slack, mail, phone…). We never got stuck on a problem and always learned from each other. Exhaustion aside, we were satisfied with the progress, and the results were better and more predictable than coding alone. 

After a few months, we started with pair programming more often and switching roles. That’s when another positive side effect surfaced: The code was always readable because if it wasn’t, you immediately had questions about it. 

The code quality, in general, was very good. And by quality, I’m referring to Dave Farley’s description: “The ability to change software easily, safely, and with confidence is a marker of its quality.“. I would say that the solutions we implement regularly are the best that team could implement (in a similar timeframe), regardless of the way of the work.

When we switched to trunk-based development, the experience was even better. My favorite part was no pull requests or pull request reviews. The code was reviewed continuously, and since we had solid automated tests, we got all the benefits of continuous integration. 

Mob programming 

If two programmers do a better job than one, then three, four, or more programmers must do it even better, right? After our initial success with pair programming, we decided to try mob programming as well. 

Whether you call it mob/team/ensemble/collaborative programming or software teaming, the practice follows Woody Zuill‘s definition from “Software Teaming” book: All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.

Or, in more practical terms: 

Software Teaming is a software development approach where the whole team works together on the same thing, at the same time, in the same space, and at the same computer. This is similar to Pair Programming, where two people sit at the same computer and collaborate on the same code at the same time. However, with Software Teaming, we extend the collaboration to everyone on the team while still using a single computer for writing the code and doing other work.

Woody Zuill, Software Teaming

We were doing mob programming sessions online, sharing screens the way we do when pair programming. It showed the same benefits as pair programming but wasn’t much of an upgrade from it. 

We noticed it was even harder to stay focused. Usually, the driver and one navigator were actively paying attention, but others got distracted by other work. We opted to do more pair programming sessions instead but are leaving our options open. 

Since we have been spending more time at the office recently, we will try to do mob programming sessions live to see if it makes a difference. If you’d like to know more about mob programming or try it out yourself, check the aforementioned book “Software Teaming.” Dave Farley also has a great video on the topic, and Thierry de Pauw shared a lot of practical tips & tricks in this thread. 

Intrigued? I certainly hope so! 

Pair programming and trunk-based development have proven to be an excellent combination for us. We also started practicing test-driven development with more discipline to see if it would improve our work. That combination resulted in continuous progress and predictive feature releases every time we used it. 

If this article has motivated you to try pair programming, here are some great resources to get you started: 

1. On Pair Programming – Birgitta Böckeler, Nina Siessegger 
2. Key to Pivotal Software’s success: Pair programming! (Rob Mee) 
3. I’ve Pair Programmed for 30,000 Hours: Ask Me Anything! — Joe Moore 
4. You Must Be Crazy To Do Pair Programming • Dave Farley • GOTO 2022 
5. Remote Pair Programming Good Practices – Thiago Ghisi 

And if you are already pair programming, share your experience with me on Twitter or LinkedIn! 

The post Two years into pair programming: The good and the challenging  appeared first on ShiftMag.