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.
Tue 14 Feb 2017 13:36 EST
Mon 13 Feb 2017 11:20 EST
In programming, the fundamental notion of an object is the bundling of data and behavior. This provides a common data context when writing a set of related functions. It also provides an interface to manipulating the data that allows the object to control access to that data, making it easy to support derived data and prevent invalid modifications of data. Many languages provide explicit syntax to define classes, which act as definitions for objects. But if you have a language with first-class functions and closures, you can use these constructs to create objects using the Function As Object pattern (originally described by Eugene Wallingford).
Mon 13 Feb 2017 11:18 EST
The agile uprising podcast has been doing a series of interviews with the authors of the agile manifesto. Here is my interview, where I reveal that I remember little of the event, but can describe a bit about the context of the time that led to it. We also talk a bit about how the agile world has developed since.
Tue 07 Feb 2017 09:02 EST
Towards the end of last year I attended a workshop with my colleagues in ThoughtWorks to discuss the nature of “event-driven” applications. Over the last few years we've been building lots of systems that make a lot of use of events, and they've been often praised, and often damned. Our North American office organized a summit, and ThoughtWorks senior developers from all over the world showed up to share ideas.
The biggest outcome of the summit was recognizing that when people talk about “events”, they actually mean some quite different things. So we spent a lot of time trying to tease out what some useful patterns might be. This note is a brief summary of the main ones we identified.
Wed 25 Jan 2017 09:46 EST
Synthetic monitoring (also called semantic monitoring ) runs a subset of an application's automated tests against the live production system on a regular basis. The results are pushed into the monitoring service, which triggers alerts in case of failures. This technique combines automated testing with monitoring in order to detect failing business requirements in production.
Wed 18 Jan 2017 00:00 EST
Continuous Integration is a popular technique in software development. At conferences many developers talk about how they use it, and Continuous Integration tools are common in most development organizations. But we all know that any decent technique needs a certification program — and fortunately one does exist. Developed by one of the foremost experts in continuous delivery and devops, it’s known for being remarkably rapid to administer, yet very insightful for its results. Although it’s quite mature, it isn’t as well known as it should be, so as a fan of the technique I think it’s important for me to share this certification program with my readers. Are you ready to be certified for Continuous Integration? And how will you deal with the shocking truth that taking the test will reveal?
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 it continues to be an interest of mine.
I’ve recently posted 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 philosphy 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.
photo: Manuel Gomez Dardenne