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.


photostream 104

Sat 03 Dec 2016 09:55 EST

Regents Park, London, England


Bliki: FunctionLength

Wed 30 Nov 2016 08:58 EST

During my career, I've heard many arguments about how long a function should be. This is a proxy for the more important question - when should we enclose code in its own function? Some of these guidelines were based on length, such as functions should be no larger than fit on a screen . Some were based on reuse - any code used more than once should be put in its own function, but code only used once should be left inline. The argument that makes most sense to me, however, is the separation between intention and implementation. If you have to spend effort into looking at a fragment of code to figure out what it's doing, then you should extract it into a function and name the function after that “what”. That way when you read it again, the purpose of the function leaps right out at you, and most of the time you won't need to care about how the function fulfills its purpose - which is the body of the function.

more ...


Bliki: HiddenPrecision

Tue 22 Nov 2016 12:54 EST

Sometimes when I work with some data, that data is more precise than I expect. One might think that would be a good thing, after all precision is good, so more is better. But hidden precision can lead to some subtle bugs.

more ...


The Thrilling Adventures of Lovelace and Babbage

Sun 20 Nov 2016 15:48 EST

As a rule, I don't do book reviews. My main area of activity is software development, and I know too many authors. If I started reviewing books it would be an endless task. So I just don't do it.

But I can't help writing a few lines about The Thrilling Adventures of Lovelace and Babbage, drawn and written by Sydney Padua. The book is mostly graphic novel, but with a sizable dollop of fascinating history thrown in. It opens with a comic book narrative of the collaboration between Countess Lovelace and Charles Babbage, which explains why we refer to Countess Lovelace as the first computer programmer.

more…


photostream 103

Sun 20 Nov 2016 09:40 EST

Stoneham, MA


Bliki: ValueObject

Mon 14 Nov 2016 10:39 EST

When programming, I often find it's useful to represent things as a compound. A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency. A date range consists of start and end dates, which themselves can be compounds of year, month, and day.

As I do this, I run into the question of whether two compound objects are the same. If I have two point objects that both represent the Cartesian coordinates of (2,3), it makes sense to treat them as equal. Objects that are equal due to the value of their properties, in this case their x and y coordinates, are called value objects.

more ...


Bliki: AliasingBug

Mon 14 Nov 2016 10:38 EST

Aliasing occurs when the same memory location is accessed through more than one reference. Often this is a good thing, but frequently it occurs in an unexpected way, which leads to confusing bugs.

more ...



Refactoring

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:

  • JavaScript offers many targets for refactoring, so Refactoring a JavaScript Video Store takes the original video store example from the book and explores it in JavaScript. It outlines four directions you can take the refactoring: a nested function with a dispatcher, using classes, and transformation using an intermediate data structure.
  • 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.
  • As a program grows in size it’s important to split it into modules, so that you don’t need to understand all of it to make a small modification. In Refactoring Module Dependencies I modularize a small example using layering and introducing Service Locator and Dependency Injection. I illustrate these using both Java and JavaScript so you can see how this modularization looks in different languages.
  • 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.

TW logo

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





tags

API design · academia · agile · agile adoption · analysis patterns · application architecture · application integration · bad things · big data · build scripting · certification · clean code · collaboration · computer history · conference panels · conferences · continuous integration · data analytics · database · delivery · design · dictionary · distributed computing magazine · diversions · diversity · documentation · domain driven design · domain specific language · domestic · encapsulation · enterprise architecture · estimation · evolutionary design · expositional architectures · extreme programming · gadgets · ieeeSoftware · infodecks · internet culture · interviews · language feature · languageWorkbench · lean · legacy rehab · legal · metrics · microservices · microsoft · mobile · model-view-controller · noSQL · object collaboration design · parser generators · photography · podcast · popular · presentations · privacy · process theory · productivity · programming platforms · project planning · projects · recruiting · refactoring · refactoring boundary · requirements analysis · retrospective · ruby · scrum · software craftsmanship · talk videos · team environment · team organization · technical debt · technical leadership · test categories · testing · thoughtworks · tools · travel · uml · version control · web development · web services · website · writing

2016 · 2015 · 2014 · 2013 · 2012 · 2011 · 2010 · 2009 · 2008 · 2007 · 2006 · 2005 · 2004 · 2003 · 2002 · 2001 · 2000 · 1999 · 1998 · 1997 · 1996

All Content