Empirical Software Design Q/A

Questions from the Goto CPH keynote briefly answered

Here are the questions submitted during my keynote. They’ll help me refine the presentation, so thanks to everyone who wrote in. Here are quick answers.

In product led organizations, you will usually gradually iterate design as new requirements surface. But how do we avoid letting business progression be too tied up to the inherent uncertainties of structural changes?

By mastering the skills of large changes in small, safe steps. Feature development may slow, but who knows? Tidying first can pay off immediately.

You’ve lost me on interruptible and parallels. Could you expand on that please again?

I definitely went over that too fast. Design changes should be interruptible. We should be able to make half a change & then pause before the other half. This preserves the flow of features. There’s a skill to slicing & ordering changes, which I hope to understand well enough to explain in the next book.

Parallels is the skill of maintaining the old & new designs for a time together. Parallels exist at all scales, from temporarily redundant function parameters to whole redundant systems.

Do you think ideas like tik-tok releases (one more focused on features, one more focused on cleaning up) are a good way to hold the balance (without killing the relationships)?

I’d prefer to shorten the loop. From the macro it looks like features & structures are advancing simultaneously while at the smallest scale they are strictly segregated from each other.

Kent: How is the structure made visible for the feature focused people?

1. Writing code intended to communicate.

2. Those making design changes accepting the responsibility of communicating those changes to affected folks & helping affected folks learn & evolve their code.

Which strategy would you suggest to cover all Social, Software and Economic concerns in requirements gathering meetings before starting to design a software solution?

Admit that you can’t cover all social, software, & economic concerns before starting to design. Problem understanding & solution implementation co-evolve.

You mentioned the value in options for upfront design, what about the problem of over engineering for options that do not get used, was this a waste of seconds? I am thinking about the principle "YAGNI" (you aint going to need it)

Good catch. I should have said “the speculative value of upfront options”. Might exist, might not.

in a startup context, how do you reconcile the tidy first principle with the idea that earning earlier is earning more? tidying could easily slow time to market for a new feature.

Survival trumps NPV. Do what’s necessary to keep the system alive. If that means deferring design, defer design. If that means slowing features for design, slow features.

How the Tidy First’s Social, Software and Economic imperatives could be aligned with the FinOps Iron Triangle: Costs, Quality and Time?

I just published about this. I think the Iron Triangle is misleading for software. Scope is the missing variable that lets you stabilize quality, which improves time & cost.

what are your suggestions to solve the outdated documentation issue? It’s not always possible to get rid of all kind of documentation, in software development, especially in large companies.

In that moment as a later reader, you don’t want someone to have written documentation 3 years ago, you want answers to your questions now. LLMs reasonably promise to provide these answers.

Is there any way to study coupling through percolation theory? With the goal of figuring out what’s the degree of coupling that cause the big crisis?

New rabbit hole for me. Thanks!

Can you design in avalanche protection? Something that stops avalanches in case they got started. Did you see something / maybe an pattern that help to prevent this?

Some. Implementation Patterns are some of the lowest level coupling stoppers.

What aspects, if any, of Extreme Programming do you find hold less true today than they did, when you published your book on the topic initially?

The values are spot on, except Simplicity. Success stories are invariably complex, even though you can simplify at times.

The principles hold. The practices can all be taken up a notch.

The second big jump in my thinking is 3X: Explore/Expand/Extract. XP morphs as it addresses the succeeding risks of irrelevance, inability to scale, & inability to sustain.

My biggest fear, though, is that none of it really matters. We see successful businesses all the time that contradict the values & principles, not even just the practices.

How Tidy First Idea-Structure-Feature concept live together with TDD considering that the refactoring is the last phase and not the second one?

They contradict each other. Sometimes you have to use your brain.

Kent, did you want to write this book or felt that the field needs you to write this book?

I needed to write these books so I could (finally) understand software design. I see so many folks struggling with development when they don’t understand fundamental principles, so I hope they find the books helpful.