Changing Legacy Code with Continuous Delivery

How to adopt Continuous Delivery practices for Legacy code? Adopting CI/CD is a big change. It touches on many aspects of the design and operation of organisations and systems. Introducing CD, and DevOps, to legacy systems requires specific techniques. Legacy Code Refactoring, Legacy Code Testing. Changing Legacy code, and legacy organisations, is complex and takes software craftsmanship and software engineering skills.

Continuous Delivery is a well-proven approach, but most organisations aren’t Amazon or Netflix. Most organisations start from a position of code and processes that were not designed to reliably and repeatably produce a releasable output every week, let alone multiple times per day!

In this episode, Dave Farley explores how to introduce Continuous Delivery to such organisations with lots of tips and advice on addressing some of the commonest technical barriers to improving automated testing, configuration-management and enabling much more frequent, reliable, releases.

-------------------------------------------------------------------------

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble

-------------------------------------------------------------------------

--------------------------------------------------------------------------

[iskabin]

Having someone with experience talking about those things is a gem! Thanks Dave!

[murrayvarey]

Fantastic video.

I like to put a positive spin on Michael Feather's definition: Legacy Code is *valuable* code without tests. This is why legacy code is so difficult to change, as we're naturally concerned about disrupting our users' lives. Your last point is spot on - real change happens at the organisation level. (Unless you do it on the sly, of course ... )

Thanks for all the excellent content Dave!

[mikekrzych]

Im extremely lucky I found your channel. Thank you so much for sharing your knowledge and experience in a well structured and organized way. I wish I could speak my mind half as good as you - my life would've been so much easier and less frustrating ;) I'm a huge fan of the content you make. Thanks, and wish you all the best.

[gonzalowaszczuk]

I would say that code with tests can still be legacy code

The tests themselves could be "legacy". That is, the tests are not maintained, are not understood, do not represent real behaviors of the system, are too coupled to the implementation, etc. Just because a test exists it doesn't mean it's a good one.

Second, I believe that understanding and knowledge also plays a part. You can have the perfect piece of code, modular, testable, with tests, etc, but nobody in the team knows what it is really for, nobody in the business knows what value it provides to the company, but nobody wants to remove it because there might be some other consumer that uses that code (e.g if it's a web service). Lack of understanding and knowledge makes such code legacy too.

[chrisjenkins]

Thanks for doing this great little talk. I enjoyed it a lot and it gave me some things to talk about with the team.

+1 to a talk about refactoring legacy code if you're willing to do one in the future... Is be very interested to watch it :-).

[Ruskialt]

One simple yet effective step in refactoring is to simply move fields to the top of the class. This way is is often more obvious what the class actually is. Also moving public members to the top. And make everything private than can be. And everything static that can be.

[Bozeman]

I was watching another of your videos and I was thinking to myself "But what if our codebase is already extant and definitely did not follow BDD/TDD in its creation?" Then this video auto-played.

[xtrailz]

Your examples refer to legacy code written in *modular* languages such as C and Java. It's much harder when the language is not modular and the experts who understand it have left the company or retired.