People at conferences and meetups often ask me what I would recommend learning X or Y. And I’m always happy to give some suggestions depending on the experience level of the person that asked. Unfortunately, this doesn’t scale very much, so here are my general recommendations on learning something very effective. This time: Legacy systems.

Legacy Systems are systems that you are afraid of to change but are necessary because they make all the money in your company. Thus, developers often have to maintain these old codebases and are angry that they cannot use the newest shiny things out there. I think that legacy code has its own charm and challenges that are much more interesting than just gluing together some frameworks in a green-field project.

So here are my TOP 5 learning resources that support you in learning to give legacy systems more love:

TOP 1: legacycode.rocks (Podcast/Community)

Link: https://www.legacycode.rocks/

A podcast (and community) created by Andrea Goulet and M. Scott Ford from Corgibyte about the world of modernizing existing software applications. This is my number one, because with Andrea gave me the confirmation that working on improving legacy systems is still a thing! She also introduced me to the concepts of different types of developers: makers and menders.

 

TOP 2: Working Effectively with Legacy Code (Book)

Link: https://learning.oreilly.com/library/view/working-effectively-with/0131177052/

 

The classic book from Michael Feathers which got me into all the legacy system stuff. With this book, I’ve learned that there is hope for all the old systems out there. There are many recipes in there for improving your old code base but also some tips for decent “Frankensteining”, where you just try to get your absolutely last features into the software system (just to keep it alive for a short period of time).

 

TOP 3: Object-Oriented Reengineering Patterns (Book)

Link: http://scg.unibe.ch/download/oorp/

 

The book I’d read parallel to Michael Feather’s book some years ago. Great patterns explained in great detail. Albeit the foreword by Martin Fowler, it seems that his book wasn’t a success. Good for us, because now there is a free edition of this book available online! Unfortunately, in some parts, this book might be a little bit outdated.

 

TOP 4: Easy rewrites with ruby and science! (Online video)

Link: https://www.youtube.com/watch?v=kgDqUHWVw4A

A great story told by Jesse Toth about rewriting the permission system at GitHub. For me, it was very interesting that there is also hope for rewriting mission-critical systems “on-the-fly” thanks to the great ideas of the involved software engineers!

TOP 5: Architecture Improvement Method aim42 (Online Guide)

Link: https://aim42.github.io/

aim42 is a collection of practices and patterns to support software evolution, modernization, maintenance, migration and improvement of software systems. It’s an open-source guide to support software maintainers and rewriters. I’m happy to be part of this project as a (irregular) contributor. You, too, can contribute your ideas and experiences as well, if you like!

Other valuable resources

OK, here I have to cheat a little bit because I’m really in love with working on legacy systems. So here are some additional recommendations for you (in no particular order):

Well, I could go on and on (and I will in the near future!). Ohh, and if this isn’t enough for you right now, check out https://github.com/legacycoderocks/awesome-legacy-code!

 

How did you start to learn legacy systems to love? Do you know other effective ways of learning to handle legacy systems? It’d be great to know! Just leave a comment down below so that we can discuss it!

 

Front picture from Renovus Solar, CC BY 2.0 licensed

print

TOP 5 Learning Legacy Systems

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.