Kent Beck, original (and first alphabetically) signatory of the Manifesto for Agile Software Development, gave the closing keynote address at QCon San Francisco this week. The title of his talk was Tidy First? - which is also the name of his upcoming book.

He started by presenting his personal mission to help geeks feel safe in the world, which he explains in this Facebook post.

He spoke about recently re-reading the Structured Design book by Ed Yourdon and Larry Constantine. He describes it as containing Newton’s laws for software development, the concepts and ideas are as relevant for programming today as they were when the book was first published. The book introduced the concepts of coupling and cohesion which remain as much of a challenge for software engineering today as they were when the book was published in 1975.

He says he’s spent the last 17 years learning how to explain cohesion in software design, which has brought him to the point of writing a series of three books which will explore the software design. The books can be accessed as the content is released on Substack.

He says that

Software design is an exercise in human relationships

And it is by exploring those relationships software systems come into being in the world.

The first relationship is between the idea being explored and the behaviour that will bring that idea into being. The relationship is bidirectional and evolving - the idea defines the behaviour and the existence of the behaviour can generate more ideas (now that I see this, what about that…). Underneath the idea and behaviour is the structure of the system. This is the architecture and it has a profound effect on the visible behaviour.

The structure of the system has a profound effect on the behaviour, and on the ideas that get generated because the behaviour can change. Structure influences behaviour, which results in new ideas requesting changes to behaviour which can have an impact on structure, in a continuous loop. The Tidy First? workflow causes us to pause and ask if the structure needs to be changed or should we just implement the behaviour change. If the change needs to impact the structure then Tidy the structure First - refactor the underlying architecture as needed. Do NOT try to make structure and behaviour changes at the same time, as that is where systems devolve in technical debt.

He says that there are two viewpoints involved when systems are being built, and particularly when they must be changed. The two perspectives are waiters and changers. Waiters have the idea and want to make the behaviour do the new thing as quickly as possible, changers have to maintain the code and want to tidy the structure first so the behaviour change can be made safely.

Complexity increases even further when there are multiple changers who look after different areas of the same product. The likelihood is high that the incentives of the waiters and the competing incentives of the different changers are in tension.

Software design skills are about keeping good relationships between the disparate makers and between the changers and the waiters.

The question a changer is faced with when getting a request for a change in a product often results in this code is messy - should I tidy it first before I make changes. The answer to that question is often a dogmatic of course and of course not - we want the change made as quickly as possible AND we want to keep the code base free of technical debt. Sadly you can’t have both and a decision needs to be made and the correct answer must be it depends.

He drew this image to illustrate the different relationships in the waiter-changer ecosystem.

He then explained why big up front design was a bad idea in the 1990’s and is still a bad idea today. He said that waterfall is back and some organisations are again trying to define success for software development in terms of time, cost and scope defined up front and how iterative and incremental development always the been most economically sound approach to building software systems, and is even more so today.

He discussed how Constantine’s Equivalence shows that the effective cost of a software system is the cost of changing the system. Over the lifetime of the system the cost of maintaining it will make the initial development cost a trivial portion of the overall investment. He then showed how the cost of maintaining a product is directly related to the cost of the coupling in the system. Where a change made to one element of the system causes a cascading change in another element, which causes change in another element and so on …

The overall cost of the system can be seen as the cost of that coupling plus the cost of decoupling the elements in the system. (He used elements to indicate the actual nature of the code is irrelevant in this context - it could be functions, remote procedures, Microservices or any other component that has dependencies)

The underlying structure (architecture, design) of the system is the single most important factor in the coupling/decoupling equation.

When considering the changes to a system, most will probably be made in areas that do not have many cascading couplings, however there are likely to be a few changes over the life of the product which are jackpot changes - ones where the coupling cascade is so large that the cost of making the change is astronomical. These jackpot changes are likely to constitute the vast majority of the cost of maintaining the system over its useful life.

He finished by encouraging the audience to make changes in small increments, to keep the structure of their systems clean and as decoupled as possible and to take a Tidy First approach to software maintenance.