Plitvice, Croatia (2018)
My name is Martin Fowler: I’m an author, speaker, and loud-mouth on the design of enterprise software. This site is dedicated to improving the profession of software development, with a focus on skills and techniques that will last a developer for most of their career. I’m the editor of the site and the most prolific writer. It was originally just my personal site, but over the last few years many colleagues have written excellent material that I’ve been happy to host here. I work for ThoughtWorks, a really rather good software delivery and consulting company. To find your way around this site, go to the intro guide.
News and Updates
My atom feed (RSS) announces any updates to this site, as well as various news about my activities and other things I think you may be interested in. I also make regular announcements via my twitter feed, which I copy to my facebook page.
Thu 20 Jun 2019 18:12 EDT
Mon 10 Jun 2019 12:25 EDT
Recent years have seen an explosion of interest in the microservices architectural style, which has become popular due to its ability to allow customer-oriented teams to build and deploy software independently. A common problem such teams face, however, is how to integrate their work into the user-interface, since these are often monolithic frontend codebases.
It should be no surprise that an approach to handle this has developed that's called micro frontends, which allows teams to independently deploy their user-interface into skeletal front end application. My colleague, Cam Jackson, has been using this approach and has pulled together an article to explain further why and how to do this. It digs into the benefits and downsides of the approach, implementation approaches, and a small but detailed example.
Wed 29 May 2019 10:38 EDT
A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. But the counter-intuitive reality is that internal software quality removes the cruft that slows down developing new features, thus decreasing the cost of enhancing the software.
Tue 21 May 2019 11:59 EDT
Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.
Mon 13 May 2019 13:37 EDT
Many enterprises are investing in a centralized data platform to provide support for business insights and (hopefully) automated decision making. Having worked with several of these organizations, my colleague Zhamak Dehghani feels there are fundamental problems with this common approach. These demand a shift to a more decentralized approach that draws from modern distributed architecture - which she refers to as a data mesh.
Thu 18 Apr 2019 18:47 EDT
Refactoring has become a core skill for software developers, it is the foundation behind evolutionary architecture and modern agile software development. I wrote the original book on refactoring in 2000, and recently published a second edition.
As well as the book, I’ve written several essays on refactoring here:
- While most of our logic is written directly in an imperative language, it is sometimes very useful to represent such logic in a data structure. Refactoring to an Adaptive Model describes this refactoring, which produces an adaptive model interpreted by generic code.
- When I write code that deals with external services, I find it valuable to separate that access code into separate objects. Refactoring code that accesses external services shows how I would refactor some congealed code into a common pattern for this.
- Modern languages give us the opportunity go beyond the loop as a way of handling repetitive behavior. Refactoring with Loops and Collection Pipelines provides a series of small examples of refactoring loops into my preferred approach.
- Refactoring Code to Load a Document looks at how manipulating large JSON documents can often be made easier by encapsulating a combination of loading strategies.
I discovered ThoughtWorks in 2000: then a small American company whose philosophy of software development was remarkably similar to my own. Now we’ve grown to around 4000 people world-wide, but kept the values that make us special. My colleagues have built critical systems for many clients in that time, and I’ve learned many lessons from them. While doing this, we found we often didn’t have the tools we needed, so we started to build them. This led to open-source tools such as CruiseControl, Selenium, Frank, and Moco as well as commercial products.
I have many opportunities, but I’ve stayed at ThoughtWorks because of the quality of my colleagues, who include both well-known speakers and those who may not be famous names but do an excellent job of software delivery (and feed me the information to write about). We are inspired by working with each other and our unusual three-pillar philosophy that raises professional excellence and social justice to the same level as financial performance.
And we are always looking for more great people to join our curious company. Maybe I’ll see you in one of our offices some day.
Continuous Integration and Delivery
For a long time I’ve been a champion of Continuous Integration which reduces integration risk by integrating early and often, an application of the principle of Frequency Reduces Difficulty. We’ve found CI to be a core technique at ThoughtWorks and use it almost all the time. At the heart of this is a style of development that minimizes long feature branches with techniques like Branch By Abstraction and Feature Toggles.
While this is useful, there was still risk present from software that works in the development environment to getting it to work in production. As a result we developed Deployment Pipelines to reduce this risk, moving closer to our aim of Continuous Delivery: building software in such a way that we confidently deploy the latest builds into production whenever there is a business need. We find this improves feedback, reduces risk, and increases the visibility of project progress.
For more information: take a look at my guide page on Continuous Delivery.