What Martin Fowler thinks about design
Chief scientist at Thoughtworks and author of Refactoring, Patterns of Enterprise Application Architecture and Refactoring: Ruby Edition. His bliki at martinfowler.com has been the reference text on refactoring, testing and architecture for two decades.
Martin Fowler did not write this page.
We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.
7 dated positions, 2003 to 2026, in their own words. Our reading of what Martin Fowler has said — not written or endorsed by them.
-
Their wordsMy skepticism has to be absolute and total, which means I have to be skeptical about my skepticism. And that requires that curiosity.
↗Martin Fowler & Kent Beck: Frameworks for reinventing software, again and againyoutube.com 5th of 20 in this recording
-
Their wordsI go to myself, "Well, yeah, but what do you mean by code?" Because that kind of implies nobody's writing anything. Well, we're at least doing some prompting. We're having some interaction with the genie. What's that going to be if it's not some form of code in some way? I think the nature of what code is is going to be quite possibly for a very radically different. But I think there is still a need to produce it and be able to interact with it in some way.
↗Martin Fowler & Kent Beck: Frameworks for reinventing software, again and againyoutube.com 12th of 20 in this recording
- 7 years earlier
-
Their wordseven the finest teams will inevitably create some cruft as they work
↗Is High Quality Software Worth the Cost?martinfowler.com 3rd of 3 in this piece
- 4 years earlier
-
Their wordsAlmost all the successful microservice stories have started with a monolith that got too big and was broken up
-
Their wordsThis leads to a powerful argument for a monolith-first strategy, where you should build a new application as a monolith initially, even if you think it's likely that it will benefit from a microservices architecture later on.
-
Their wordsBut even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning.
- 12 years earlier
-
Their wordsAny good developer knows that they can code the same stuff with huge variations in lines of code, furthermore code that's well designed and factored will be shorter because it eliminates the duplication.
↗CannotMeasureProductivitymartinfowler.com 2nd of 2 in this piece