Legacy Code Retreat - Uncovering Better Ways of Dealing With Legacy Software By Doing it and Helping Others Do It!

In his book “Understanding the Four Rules of Simple Design”, Corey Haines lays out the basics for getting people together for a day and practice coding better. Unhappily, many of us have to deal with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. J. B. Rainsberger has started a variation on on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to extend that pattern and have retreat for those of us who work legacy code in Java often.

We will learn and practice the classic Michael Feathers dance of

  1. Identify change points
  2. Find an inflection point
  3. Cover the inflection point (break external dependencies, break internal dependencies, write tests)
  4. Make changes
  5. Refactor the covered code.

By the end of the day, in addition to being tired and completely ready to put away our laptops forever, we will have gained valuable insights and practical experience with a topic no one likes to talk about - getting better working with legacy code!

 
2 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Legacy Java code will be made available to the group at the beginning of the day.  A brief review of how to go about Feathers' type refactoring through various types of automated tests (unit, integration, acceptance, etc) will be discussed before we begin.

The general structure works off of an hourly cadence.  The begging of the day starts with some introductory material which speaks to the skills we will use during the day related to refactoring, etc.  Then, in the beginning of each hour, participants will be asked to pair with a partner for 45 minutes.  They will be asked to improve the legacy code as the day progresses.  At the end of every 45 minute pairing, about 15 minutes will be spent facilitating the participants to show what they learned and how they can improve the code base.  People will be asked to switch pairs to start again.  Before work on the next pairings takes place, participants will be asked to commit one of the prior round's work to the codebase.  We repeat for as many rounds as we can get in for the day.

Learning Outcome

I expect that participants will come away with new skills that they glean from one another, such as different ways of organizing tests and refactoring code.  

Participants will probably finally understand the perspective that just rewriting the code may not be the appropriate thing to do when we don't really understand what the code does in the first place.  

Everyone will have a chance to hone their skills and have valuable lessons, tricks, and techniques to take back to their day jobs.

Target Audience

Java developers who want to get better at writing better code, even within the confines of a legacy codebase.

schedule Submitted 8 months ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  7 months ago
    reply Reply

    Hi Howard,

       I like the legacy code retreat approach.  Have you ran these before?  If so, what have you learned doing these before that you will bring forward in this one?

     

    Best,

    Joel

    • Howard Deiner
      By Howard Deiner  ~  6 months ago
      reply Reply

      Hi Joel!

      Legacy code retreats tend to be popular with IT types and people who are trying to remake programming careers in older languages, etc, and find a way to work in a more modern world with modern skills.  

      What I've learned is that you can't be subtle in demonstrating learnings.  It's important to find examples of good change and get the crowd hearing and seeing what that looks like.  I prefer the person who does the change to be excited and explain to everyone else what they did and why.  I can always chime in with more support if needed.  But I don't want to be the only one to show people what refactorings I would do.  I need them to own the excitement.  My job is to make sure that the day has those wonderful moments of insight.

      --  howard

      [sorry for the amount of time I took to respond - i'm recuperating from a medical thing]

       

  • Abraham L C
    By Abraham L C  ~  7 months ago
    reply Reply

    For me, it looks this topic is not very suitable in the stream of CI and CD.

    'Find an inflection point' - Can you please add more details of this subject? For me, this looks critical.

    Please respond.

     

    Best Regards

    Abraham L C 

    • Howard Deiner
      By Howard Deiner  ~  7 months ago
      reply Reply

      Hi Abraham!

       

      I know that this workshop isn't about the tools or normal topics that go into CI/CD.  The reason that it's here is that the primary reason that legacy code doesn't work well in a CI/CD framework is that it's normally too hard to maintain, and therefore lengthly to fix or extend.  What's missing is usually a quality factor.  The goal of refactoring legacy code isn't to necessarily add unit tests, but to bring up the quality in the code, usually by adding stabilizing characterization tests and then ensuring that any changes do not adversely affect functionality.

       

      The inflection point terminology comes from terminology that Michael Feathers used before he wrote his "Working Effectively With Legacy Code" book.  Generally, inflection points identify the lowest places in your code that changes to an area must go through.  Perhaps an controller, interface, or set of model classes that changes will have to be made to, but that can still allow us to maintain current functionality. In his book, Feathers now calls these places "seams", which he defines as "... a place where you can alter behavior in your program without editing in that place.”  

      Regardless of the terminology that we use, the real work of the day comes with practicing the five steps and showing others how to do that.

      Thanks for your interest.  Hope that clears things up a bit.

       

      --  howard

  • Shiv Sivaguru
    By Shiv Sivaguru  ~  7 months ago
    reply Reply

    How long is this session planned for? the 960 minutes duration mentioned, 45 minute pairing + 15 minute discussion repeated etc do not add up.

    Please clarify

    • Howard Deiner
      By Howard Deiner  ~  7 months ago
      reply Reply

      Hi Shiv!

       

      Sorry I wasn't clear enough.  We will work the day in hours.  45 minutes of the hour for refactoring.  15 minutes for retrospective and reflection.  That will continue for the entire day, with a longer wrap up in the last session to speak about what we learned during the day.  I updated the "Outline/structure of the Session" section to try to better reflect that.  Oh.  And I meant this to be one day - 480 minutes.  Updated that as well...

       

      I hope that clarifies things.

       

      --  howard


  • Liked Woody Zuill
    keyboard_arrow_down

    Mob Programming: A Whole Team Approach

    Woody Zuill
    Woody Zuill
    schedule 8 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

    Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

  • Liked Fennande van der Meulen
    keyboard_arrow_down

    The Power of Purpose - workshop on How purpose drives employee happiness and company results

    Fennande van der Meulen
    Fennande van der Meulen
    Maartje Wolff
    Maartje Wolff
    schedule 8 months ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Having a clear purpose in both life and work is essential to happiness. And, science and business support this view. Companies with a clear purpose perform better than companies without. Purpose is increasingly seen as the key to navigate the volatile and complex world we live in. And, people with a purpose in their live longer and are healthier. However, finding your purpose, your personal and companies purpose, is not an easy task. In this workshop we discuss what purpose means and key elements of a sustainable and meaningful purpose. We elaborate the four steps to identify the company purpose and how to build your business around it.

  • Liked Nayan Hajratwala
    keyboard_arrow_down

    Refactoring Legacy Code Guided by Simple Design

    Nayan Hajratwala
    Nayan Hajratwala
    schedule 8 months ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    Are you frustrated by the many trivial examples that show up when you google "refactor legacy code"? How do you translate these examples to your real-world code base? Sometimes it's just easier to give up on the refactoring and increased test coverage, reserving these techniques for the ever elusive greenfield project. To help you with this dilemma, Nayan will walk through a real legacy Java code base, and perform some safe refactorings required to bring the code under test. All of this will be done under the guidance of the Four Rules of Simple Design (Pass the tests, DRY, Reveal intent, Minimize moving parts).

  • Fabiola Eyholzer
    Fabiola Eyholzer
    schedule 8 months ago
    Sold Out!
    45 mins
    Keynote
    Advanced

    There is growing interest in learning more about Agile HR and its impact on individuals, teams and organizations.

    It is important to separate fact from fiction: What are the real threats and opportunities of bringing Lean | Agile values, principles, and practices to HR? What can we expect in the future? Through anecdotal evidence and case studies, the session will explore the potential of Agile HR as well as provide guidance on how to approach the transformation.

     Issues covered in the presentation include: information on how to embrace the new talent contract, create inspiring, engaging, and fun places of work, shift to an iterative performance flow, take the issue of money off the table, support growth within an Agile enterprise.

  • Liked Rajith Raveendranath
    keyboard_arrow_down

    From Monolith to Micro Service - A Kick Start

    Rajith Raveendranath
    Rajith Raveendranath
    schedule 8 months ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    [Update based on the panel review]

    Inspired by Martin Fowler's introduction to micro services (https://www.youtube.com/watch?v=wgdBVIX9ifA);

    The demo will introduce the "ABC"s of the transition to micro services. We will refer to the Hadoop Distributed File System open source and demonstrate to (re)design the NameNode module as a micro service. This will introduce the three primary challenges and their possible solutions as in;

    1. Componentize using Services instead of the conventional componentization using the design

    2. Data segregation using an event driven framework to separate the centralized data across services

    3. Accessing a micro service as a web service instead of an orchestrated access; the delegate & facade patterns will be demoed to loosely couple the interfaces

     

    The demo will conclude with a listing of the next steps in transition, which need to be considered after the primary challenges are addressed.

  • Liked Chris Edwards
    keyboard_arrow_down

    The Agile Architect: Turning Followers into Leaders

    Chris Edwards
    Chris Edwards
    schedule 8 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    "The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

    An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.

    How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.

  • Liked Howard Deiner
    keyboard_arrow_down

    How We Get Agile Transformations Wrong By Trying to Do It All So Right

    Howard Deiner
    Howard Deiner
    schedule 8 months ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.

    Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

    But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

    I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can't logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.

    This session will speak to the specifics of the whats and whys.

  • Liked Howard Deiner
    keyboard_arrow_down

    Taking a Fresh Look at Continuous Delivery - What are We Really Trying to Achieve, and How Do We Do That?

    Howard Deiner
    Howard Deiner
    schedule 8 months ago
    Sold Out!
    20 mins
    Talk
    Beginner

    Organizations are embracing Continuous Delivery (CD) for many reasons nowadays, including:

    • better throughput and stability of systems built and managed
    • better effectiveness of the organization, resulting in better financial outcomes for the organization
    • better job satisfaction for members of the organization
    • a desire to play with shiny new things and engage in resume driven development

    When we take a deeper look at what the goals are, and talk about how we accomplish those goals, many times the discussion starts to devolve into a discussion of tools and tool capability. And many times, the deciding factors of one tool versus another tool speak to the capabilities of the tools to work in the existing organizational structure.

    But this approach is flawed. If we view CD as an organization change to achieve the goals stated before, then we should expect that the organizational structure, as well as the organization’s guiding principles will have to change as well.

    This talk will center around the premise that the changes that are needed to accomplish CD, and subsequently achieve the benefits associated with that involve the use of new tools (potentially bright and shiny, as well as resume enhancing). But the tools are merely necessary but not sufficient in attaining the organizational’s CD goals. True teamwork both from both a technical team perspective as well as inter-team collaboration as required to truly get to full positive outcomes for DevOps based CD. We’ll speak to some tools, but mostly talk about good teams and the top quality software that they need to produce, and how they need to go about that.