diff --git a/handbook/troggle/trognotes.html b/handbook/troggle/trognotes.html
index 54f7aa6c0..bd3478e64 100644
--- a/handbook/troggle/trognotes.html
+++ b/handbook/troggle/trognotes.html
@@ -67,6 +67,7 @@ the <a href="trog2030.html">2030 plan</a>, <a href="trogspeculate.html">architec
 the characteristics of code and of organisations that mean that it is a good idea to give up, and if so how to
 manage the rewrite. The answers are "almost never" and "don't": as explained in <a href="trogkill.html">this summary of the book 'Kill it with 
 Fire'</a>.
+  <p>"...you cannot split up a large established codebase without first understanding it. I have seen large codebases successfully split up, but I have never seen that done by a team that wasn’t already fluent at shipping features inside the large codebase. You simply cannot redesign any non-trivial project ... from first-principles", <a href="https://www.seangoedecke.com/large-established-codebases/"><em>Mistakes engineers make in large established codebases</em></a>, Sean Goedecke.
 
 <p>Replacing old systems, and changing their architecture, while keeping them operating continuously, is now 
 <a href="https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html">a well-understood