Tag Archives: Extreme Programming

David Scott Bernstein asked me to review his book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.

Looks like a book for software developers. Can I review this book, it’s 35 years ago that I was a programmer in the pre-OO era? But I started reading and I am glad I did it. There are some chapters (3 practices) with are definitely for the real software developers but the rest of the book is for a much broader audience. The book gives you great insight why so many organizations struggle with the implementation of agile practices and what you have to do to overcome these struggles!

Many organizations want to introduce agile, sent some people to scrum master or product owner training classes and think it will flow. Understanding time-boxes, daily stand-ups, and retrospectives doesn’t make your organization agile. This book shows that this is just a very first step. To fully benefit of agile it will take a software development team at least a year of practice, making errors and learn from them to fully understand e.g. Extreme Programming, pair programming, and Test Driven Development. Or with other words to achieve mastery you need more than skills and ability. You have to follow the three stages of the Japanese martial art Aikido Shu-Ha-Ri: Shu (knowledge), Ha (put theory into practice) and Ri (practice and theory begin to dissolve: highest level of mastery).

The book is divided in two parts. Part I focuses on the legacy code crisis, and part II, the biggest part of the book, gives nine practices to extend the life, and value, of your software.

Part I is divided in three chapters. Chapter 1, Something is wrong elaborates on what happens when:

Software is created using the waterfall method resulting in legacy code

Software developers have little knowledge of how software is constructed and how software becomes legacy code

Batching features into releases.

Chapter 2, Out of chaos questions the Chaos Report definitions from the Standish Group. The author shows that using these definitions you still have no clue if a project is really a success or not. Also the usage of failed (cancelled) projects is misleading. To stop a project is in most cases not a failure, because it is related to external circumstances. But the final conclusion of the Chaos Report – that the software industry has a long way to go – is right. The rest of the chapter focuses on other studies showing that most of software costs are related to inefficiency and maintenance costs and are costing the industry a least tens of billions of dollars a year.

The last chapter of part I, Smart people, new ideas introduces agile to start moving in the right direction. Using daily stand-ups, time-boxes (according to the author better to use scope boxing) is not enough. Continuous attention to technical excellence and good design enhances agility and must be the top priority for the next ten years.

The second part, the core of the book, describes nine practices:

Say What, Why and Whom before How

Build in small batches

Integrate continuously

Collaborate

Create CLEAN code

Write the test first

Specify behaviours with tests

Implement the design last

Refactor legacy code

These nine practices will help you to develop software (or use agile) in the right way. To build bug free software that is simple (and therefore cheaper) to maintain and extend. Or as David stated “Build better / risk less”.

Every practice is explained with much detail and based on real life examples from David and at the end you will get two key topics with practical strategies to implement these practices. See the attached figure, showing these strategies for all nine practices. You will also get references to books, websites and videos to get an ever much deeper insight in the mentioned topics. To download: beyond legacy code (practices, 150807) v1.0

e.g. a great video to explain the effect of work in progress (WiP, Kanban system) by comparing the highway traffic paterns, by Hakan forss:
Or explaining MOB programming: what does it mean if all the brilliant people working at the same time, in the same space, at the same computer, on the same thing.

To summarize, If you start using agile and understand the agile basics and you want to take the next step to leave ‘agile in name only’ and really want to use the agile way of working, this book is a must read.