Leading a Legacy Software Team

How to turn a chaotic software project around and lead it from legacy code to success

Your company and its software is a success, feature requests and bug reports are coming in. But you feel overwhelmed, the source code becomes harder and harder to change, and your boss puts the pressure on you to do more.

If this feels familiar, this book is for you.

You are not the first software team leader to experience the pressure of a growing legacy code base. This book shows you the way out.

Sign up to the newsletter to be notified when it is ready:

Read Free Sample 📄 Table of Contents 📖

About the Book

Leadership Tips for Software Projects

This book will teach you how to turn a chaotic software project around and lead it from legacy code to success

  1. Understand the tools of software development

  2. Motivate and coach a professional team

  3. Master the communication with the customer

  4. Improve yourself be becoming learning expert

Get a free Sample Chapter

Table of Contents

  1. Preface
  2. 1. Software Forges
    1. 1.1. Keeping Code under Version Control
    2. 1.2. Choosing a Software Forge
    3. 1.3. Creating a Version Control Workflow
      1. Trunk Based Development
      2. Forking, branching and merging
      3. Preparing a branch for code review
      4. Deciding on a Release Scheme
      5. The benefits of good commit messages
      6. How to structure a commit message
      7. Document your Workflow
      8. Chapter Summary
    4. 1.4. The continuous integration server
      1. Choosing a Continuous Integration Server
      2. Continuous integration minimal setup
      3. Setting up a local continuous integration server
      4. Using a continuous integration service in the cloud
      5. Connect continuous integration to the software forge
      6. Connecting with Code Review
      7. Securing Jenkins
      8. The Pre-Merge/Pre-Integration Check
      9. The Deployment Pipeline
      10. Chapter Summary
    5. 1.5. Taking control of the build process
      1. Recording the status quo
      2. Where to start with improvements
      3. Implementing a central build script
      4. Chapter Summary
    6. 1.6. What is Static Code Analysis
      1. How Static Analysis can help you
      2. Static Analysis is run as part of the CI Build
      3. Defects found in new or changed code make the build fail.
      4. The configuration of the static analysis Tool is also kept under version control.
      5. Developers can run the Static Analysis Tool on their local machine as a script
      6. Developers can run the Static Analysis Tool as a Commit Hook
      7. Developers can run the Static Analysis Tool integrated into the IDE
      8. Chapter Summary
    7. 1.7. Keeping a Bug Tracker
      1. What to track on tickets?
      2. Required information in a ticket
      3. Simple rules for successful Bug Tracking
      4. Chapter Summary
    8. 1.8. Access rights for software forge accounts
      1. Customer or User Accounts
      2. The Administrators Account
      3. Service Accounts
      4. The Role of Internal Support
      5. Access Rights Chapter Summary
    9. 1.9. Creating a Release Engineering Plan
      1. Example Release Plan
    10. 1.10. What is hallway usability testing
      1. Updating your Usability Testing Machine from Nightly Builds
      2. Reduce the Feedback Loop with a Usability Testing Machine
      3. Have a physical Machine even for Web Applications
      4. Testing your Update Routine every Day
      5. Observe but do not interfere
    11. 1.11. Maybe your software needs a demo dataset
    12. 1.12. Code Archaeology
      1. Switching between version control systems
      2. Removing sensitive information
      3. Reformatting a codebase
      4. Chapter summary
  1. 2. Keeping a Team Together
    1. 2.1. The team vision
    2. 2.2. Roles in a software team
      1. Role: The native UI advocate
      2. Role: The application workflow optimizer and ergonomics expert
      3. Role: The server admin
      4. Role: The tireless packager and distribution maintainer
      5. Role: The obsessive benchmarker and tester
      6. Role: The pragmatic and feature driven developer
      7. Role: The outspoken user
      8. Chapter Summary
    3. 2.3. Pair Programming
      1. Distributing knowledge
      2. Training new team members
      3. Is pair programming duplicate effort
      4. Successful pair programming
      5. Chapter Summary
    4. 2.4. Code reviewing
      1. Code reviewing tools
      2. The code review process
      3. Enforcing reviews
      4. Reviewing all commits
      5. How to review large changesets
      6. Code reviews or pair programming
      7. The code review checklist
      8. The role of the code reviewer
      9. Chapter Summary
    5. 2.5. Test driven development
      1. Misuse of generating coverage data
      2. Enabling test driven development
    6. 2.6. The scrum framework
      1. How does scrum work
    7. 2.7. The review/demo day
    8. 2.8. Creating a team vision
      1. The fire squad analogy
      2. The Kitchen Crew Analogy
    9. 2.9. Chapter Summary
  2. 3. Customer Communication
    1. 3.1. Creating transparency
    2. 3.2. Roadmap
    3. 3.3. Changelog
    4. 3.4. Bug Reports
    5. 3.5. Feature Requests
    6. 3.6. Humane Error Messages
    7. 3.7. Chapter Summary
  3. 4. Self Improvement
    1. 4.1. Principles of Learning
      1. Learning Technique 1: Immersion in the Topic
      2. Deliberate Practice
      3. Deliberate Practice 1: Learning Refactoring with Katas
      4. Deliberate Practice 2: Practice the Refactoring Tools from your IDE
      5. Deliberate Practice 3: Reducing key presses
      6. Deliberate Practice 4: Over Speeding
      7. Deliberate Practice 5: Isolation
      8. Remembering lists of facts
      9. The memory palace method
      10. Getting honest feedback
    2. 4.2. Negotiation
      1. Know your emotions
      2. Know the facts and come prepared
      3. Notice the pressure
      4. Have alternatives
      5. Negotiation Mistake: Saying No to everything
      6. Negotiation Mistake: Saying Yes to everything
      7. Negotiation Mistake: Trying to always "Win" a Negotiation
      8. Chapter Summary
    3. 4.3. Good Commits (Divide, Small is Beautiful)
    4. 4.4. Software Architecture
      1. Devide and Conquer
      2. Architecture by Interfaces
  4. 5. Bibliography
  5. Index
  6. About this book

About the Author

Richard Spindler is an expert software engineer working on creating great code and great teams

He wrote the book Leading a Legacy Software Team about turning around a legacy code project and leading it to success. And he twitters at @oracle2025 about learning software engineering and working in a team.

In his experience every project accumulates technical debt, so refactoring and improving legacy code is a skill that every software developer must have.

Richard has experience in C++, Qt, GPU programming, and automotive media center software.


Read a Free Sample Chapter

This "Leading a Legacy Software Team" chapter is available as a FREE sample:

Chapter Nr 2: Keeping a Team Together

Click the button 👉 and see how you can save your legacy project.

Get Free Sample Chapter