Martin Fowler: Articles

Popular

Some articles keep showing up as regular choices for visitors. So I thought I'd put them first in case you're looking for them, or if not to see what counts as popular around here.

The New Methodology
In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.
Latest Significant Version: 2005-12-13
Is Design Dead?
For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.
Latest Significant Version: May 2004
Continuous Integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
Latest Significant Version: 2006-05-01
Inversion of Control Containers and the Dependency Injection pattern
In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.

Enterprise Application Architecture

For most of my career I've specialized in enterprise application work. Enterprise applications have their own particular challanges and techniques that work with them. These articles explore some of the patterns, principles and practices that I've uncovered in this work.

Consumer-Driven Contracts: A Service Evolution Pattern (by Ian Robinson)
This article discusses some of the challenges in evolving a community of service providers and consumers. It describes some of the coupling issues that arise when service providers change parts of their contract, particularly document schemas, and identifies two well-understood strategies - adding schema extension points and performing "just enough" validation of received messages - for mitigating such issues. Both strategies help protect consumers from changes to a provider contract, but neither of them gives the provider any insight into the ways it is being used and the obligations it must maintain as it evolves. Drawing on the assertion-based language of one of these mitigation strategies - the "just enough" validation strategy - the article then describes the "Consumer-Driven Contract" pattern, which imbues providers with insight into their consumer obligations, and focuses service evolution around the delivery of the key business functionality demanded by consumers.
Latest Significant Version: 2006-06-12
Mocks Aren't Stubs
The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing.
Latest Significant Version: 2007-01-02
Richardson Maturity Model
A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls.
Latest Significant Version: 2010-03-18 14:02 GMT
Inversion of Control Containers and the Dependency Injection pattern
In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.
Developing Patterns in Enterprise Software
A personal survey of various efforts to catalog patterns for enterprise software development.
Errant Architectures
Software Development magazine adapted chapter 7 (Distribution Strategies) of my book Patterns of Enterprise Application Architecture as an article in their magazine. I suspect they liked it due to its tone and the inclusion of the First Law of Distributed Object Design. (Registration required with CMP)
Domain Logic and SQL
Over the last couple of decades we've seen a growing gap between database-oriented software developers and in-memory application software developers. This leads to many disputes about how to use database features such as SQL and stored procedures. In this article I look at the question of whether to place business logic in SQL queries or in-memory code, considering primarily performance and maintainability based on an example of a simple, but rich SQL query.
Latest Significant Version: February 2003
Evolutionary Database Design (by Pramod Sadalage and Martin Fowler)
Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.
Latest Significant Version: January 2003
Agilists and Architects: Allies not Adversaries
At QCon San Francisco 2008 Rebecca Parsons and I gave a talk about how agile approaches work with enterprise architecture groups. At the moment there's a lot of distrust and conflict between agile project teams and architecture groups. We dig into why this is so, and explore ways that these groups can work together.
The LMAX Architecture
LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread. The Business Logic Processor runs entirely in-memory using event sourcing. The Business Logic Processor is surrounded by Disruptors - a concurrency component that implements a network of queues that operate without needing locks. During the design process the team concluded that recent directions in high-performance concurrency models using queues are fundamentally at odds with modern CPU design.
Latest Significant Version: 2011-07-12 09:30 EDT

Language Workbenches

I've recently become very interested in a new class of tools that I've called Language Workbenches. These articles explore this topic area in more depth.

Language Workbenches: The Killer-App for Domain Specific Languages?
Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.
Latest Significant Version: 2005-06-12
Generating Code for DSLs
When you build a Domain Specific Language (DSL), how do you go about making it executable. This is an easy question to answer for an internal DSL, since they are embedded into real languages. An external DSL needs more work. Here I take a simple DSL example and show a few simple ways to generate code from it.
Latest Significant Version: 2005-06-12
Language Workbenches and Model Driven Architecture
There's been a recent surge in development of tools that allow you integrate between multiple Domain Specific Languages (DSL) - tools that I refer to as language workbenches. Much of the discussion around language workbenches is very similar to the discussion around the Object Management Group's Model Driven Architecture (MDA). In my view the MDA means different things to different people - and this effects how we view the relationship between MDA and language workbenches. Certainly there groups of MDA practitioners who are using MDA ideas to build a language workbench. However my feeling is that the help MDA provides is partial, at best. A broader school of Model Driven Development (MDD) echoes many of these ideas without the links to the MDA standards - this is something that is very much in line with the ideas of a language workbench.
Latest Significant Version: 2005-06-12
A Language Workbench in Action - MPS
Using a language workbench is very different to working with traditional Domain Specific Languages. This is an example of building a small but interesting DSL using the JetBrains Meta Programming System (MPS). You can use this to get a feel of what working with language workbenches would be like.
Latest Significant Version: 2005-06-12
Video: Introduction to Domain Specific Languages
At JAOO 2005, I chaired a track on Domain Specific Languages. I opened the track with a half-hour introduction which was recorded by InfoQ and made available on their website. The talk mirrors the first part of my paper on Language Workbenches.
Meta-Introduction to Domain Specific Languages
This is my usual DSL intro talk, but done with a twist as I'm talking to a much more DSL-aware crowd than usual. So essentially I twisted into a talk about how I introduce DSLs to people.

Conference Talks and interviews

Now that video capture and distribution is so easy, more of my conference talks are available in video form.

Video: Introduction to Domain Specific Languages
At JAOO 2005, I chaired a track on Domain Specific Languages. I opened the track with a half-hour introduction which was recorded by InfoQ and made available on their website. The talk mirrors the first part of my paper on Language Workbenches.
Keynote for RailsConf 2006
As with most of my keynotes, this is an extemporary talk. Given the conference, this one has a theme of how rails impacts software development.
Keeping Software Soft
At Software Development East in 2000, I gave a keynote "Keeping Software Soft". The covered similar material to the original form of my New Methodology essay. As such it's an early description of what was later called Agile methods (the talk predated the Snowbird meeting). Dr Dobbs made the talk available in video and audio feeds. (last time I checked the underlying links were broken.)
Language-Oriented Programming and Language Workbenches
A keynote for The Server Side Java Symposium that I gave with Neal Ford. We look at the growing movement towards Domain Specific Languages, what kinds of languages exist and why they are interesting. If you're looking for one talk on the subject then my preference is for the JAOO video, but this one expands on some of the themes and is more entertaining due to Neal's presence. It would also work fine audio only, if you can find a way to extract the audio stream.
Modifiability: Or is there Design in Agility
The organizers of QCon London 2007, asked me to do a conference session on modifiability of architecture. I thought that rather than listening to me, the audience might prefer listen to some of the ThoughtWorks architects whose ideas I usually repackage: Dave Farley, Ian Cartwright, Fred George, Erik Doernenberg, and Dan North. InfoQ has now put up a video of session.
The Yawning Crevasse of Doom
A keynote for QCon 2007 that I did with my colleague Dan North. We both see the gap between developers and their customers/users as the biggest problem in software development. (We'd call it a chasm, but that word is so overused.) Here we talk about this gap, why it's important, and what we need to do to cross it. In particular we argue that the traditional role of an intermediary Business Analyst acts as a ferry, while what we really need is a bridge that enables directly contact between developers and their customers (and analysts can build and maintain that bridge). This is one of my favorite joint keynotes, both because I think the topic is so important, and because Dan is such stimulating co-speaker.
Does My Bus Look Big in This?
My colleague Jim Webber has built quite a reputation for taking a lightweight and business-oriented approach to integration in the enterprise. He also has a reputation for being a very robust and entertaining speaker. So I was as nervous as I was excited to share the stage with him for a keynote at QCon 2008. He put together a wonderfully funny presentation with some serious tidbits of meat woven through it. We then just dove in and did it - possibly helped by the pre-talk pint. We talk about the history of Enterprise Integration, the growth of systems that think they are strong but are really just fat, the role of agile thinking, the influence of the web (including Jim's unique theory on why it was invented), and how this leads to Guerilla SOA.
No Silver Bullet Reloaded
The OOPSLA 2007 conference occurred on the 20th anniversary of Fred Brooks's famous paper "No Silver Bullet". So to mark this, we had a retrospective panel, including the Mr Brooks. I was lucky enough to be invited on the panel, although I doubt they expected quite the contribution I ended up making.
Forging a New Alliance
ThoughtWorks often organizes "Quarterly Technology Briefings" - open talks for the community in cities where we have offices. In this QTB in Toronto, Scott Shaw and I talk about how to build new relationships between IT and business. It explains why we think IT departments should be disbanded.
Meta-Introduction to Domain Specific Languages
This is my usual DSL intro talk, but done with a twist as I'm talking to a much more DSL-aware crowd than usual. So essentially I twisted into a talk about how I introduce DSLs to people.
Perspectives on DSLs with Chris Sells
When I attended DSL DevCon, Microsoft's Channel 9 dragged me off to be interviewed by Chris Sells.
DSL interview with Neal Ford and Jeffery Snover (JAOO 2008)
A Microsoft Channel 9 interview of me, my colleague Neal Ford, and Jeffery Snover (creator of PowerShell). The general topic is that of DSLs - Neal and I had just finished a tutorial on the topic at JAOO 2008 and had some good conversations with Jeffery.
Democratic Political Technology Revolution
My colleague Zack Exley and I talk about the software that was used by the 2008 Obama presidential campaign. An aspect I found particularly interesting was the way in which the software enabled and interacted with the organizational approach to the campaign.
Google I/O Talk on Cloud
Rebecca Parsons and I talk about Google App Engine and the general world of clouds. In the first bit I talk about things various ThoughtWorkers learned from experiementing with App Engine, highlighting issues with testing, persistance, and concurrency. In the second part Rebecca talks about the broader issues enterprises will face with moving to the cloud.
Agilists and Architects: Allies not Adversaries
At QCon San Francisco 2008 Rebecca Parsons and I gave a talk about how agile approaches work with enterprise architecture groups. At the moment there's a lot of distrust and conflict between agile project teams and architecture groups. We dig into why this is so, and explore ways that these groups can work together.
Revitalizing Enterprise Software
AMP, an Australian financial services company, ran an internal conference called Amplify. They asked me to talk about agile software development. I thought about how to make this best fit into the overall flow of the conference, particularly since I expected a significant part of the audience to not be part of IT. I settled on talking about how IT projects can be infrastructural or strategic. This classification alters how you approach the projects, in particular on the way IT and business people should collaborate.
Three Years of Real-World Ruby
For a talk at QCon London 2009 I surveyed ThoughtWorks use of Ruby from 2006-2008 in which time we did 41 projects. My talk covers our views on Ruby's producitivity, speed, and maintainability. I conclude that Ruby should be taken seriously as a development environment. I also have an article that covers the same material if you prefer reading to watching.
Pourquoi, pas comment
Neal Ford and I gave a talk at USI in Paris (2010) on some aspects of why agile works (as opposed to how). This probes at some of the core forces that makes agile effective, rather than looking at techniques. In particular we look at role of communication and feedback and how they interplay in agile environments.
Agile Brazil Interview
Interview with Paulo Caroli and me at Agile Brazil
InfoQ Interview with Jez and me on Continuous Delivery
An interview with Jez Humble and me at QCon San Francisco in 2010

Analysis Patterns

Patterns are important to me, as they are a key technique to discussing and capturing what makes good design. Analysis Patterns were the subject of my first book, and they continue to be a topic that interests me deeply.

Patterns for things that change with time
Summarizes various patterns that you can use to answer questions about the state of an information in the past. These include questions of the form "what was Martin's address on 1 July 1999" and "what did we thing Martin's address was on 1 July 1999 when we sent him a bill on 12 August 1999".
Quantity
Handling dimensioned numbers such as: 12 ft and $9.99
Range
Treating a range of values, such as Oct 22-25 as a single object.
Accounting Patterns
In my book I included a chapter of patterns to do with accounting. Here I update and greatly expand on this topic. The primary pattern here is that of Posting Rule, which takes us from a passive accounting system to an active one. There's also discussion of entires, accounts, transactions, and the tricky matter of adjustments.
Organization Structures (Accountability)
This is a rework of the accountability chapter from the original analysis patterns book. It does some small updates to the patterns, but the main change is a complete rewrite of the chapter to put it into the new form that I'm now working with.
Dealing With Roles
A range of patterns that look at ways to handle situations where objects of a class can play different roles in various situations.
Specification
Patterns that describe how you can describe specifications of kinds of objects. Essentially the most general form allows you to encode predicate expressions as an interpreter of objects. These are useful for representing object queries, and for defining a requirement that objects need to match.
Recurring Event in Calendars
How to build an object structure that allows you to represent complicated recurring events. Such as the schedule for street cleaning when I lived in the South End of Boston.
Dealing with Properties
Many things have properties, and there are many ways to model how these properties work. These range from simple explicit properties to complex property models with an active knowledge level for validation. These patterns discuss some of the options in handling this.
Application Facades
Analysis Patterns talked about the topic of application facades. This article gives a much more in depth treatment of this idea, including a lot of sample code to help you implement it. This is also an extension of the Java example I gave in chapter 11 of UML Distilled.
UML Diagrams
I'd intended to put together UML diagrams for the patterns in the book. As it turned out I've come the view that other things were more important. Some others did work on diagrams, however, so here there are some for chapters 2-5

XP and Agile Methods

I've been long interested in the approaches of what are now called agile methods. My New Methodology article provides a summary of my perspective on them and a survey of the whole field. I've also written quite a few articles on XP, which I've been involved with ever since working on the C3 project.

It's Not Just Standing Up: Patterns for Daily Standup Meetings
Daily stand-up meetings have become a common ritual of many teams, especially in Agile software development. However, there are many subtle details that distinguish effective stand-ups and a waste of time.
Latest Significant Version: 2011-08-29
The New Methodology
In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.
Latest Significant Version: 2005-12-13
Using an Agile Software Process with Offshore Development
For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate.
Latest Significant Version: 2006-07-18
Canadian Workshop on Scaling XP/Agile Methods (by Jonathan Rasmusson and Jim McDonald)
As XP and other Agile methods gain popularity, questions are beginning to surface regarding how to scale XP beyond teams of 10-12 people. In mid February 2003 a workshop dedicated to the subject was held in Banff Alberta Canada. In this article we report on the keynote speeches from Ken Schwaber, and Martin Fowler, as well as other leading practitioners.
Latest Significant Version: March 2003
Evolutionary Database Design (by Pramod Sadalage and Martin Fowler)
Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.
Latest Significant Version: January 2003
The XP 2002 Conference
At the end of May 2002, the XP community once again descended on the Mediterranean island of Sardinia. In this article I look at the plenary speeches from Ken Schwaber, David Parnas, Enrico Zaninotto, Bill Wake, and the Standish Group's Jim Johnson. They lead me into some thoughts on the essence of agile development, the role of mathematical specifications, the complexity of irreversibility, metaphor, and the best way to drastically cut software costs.
Latest Significant Version: 2002-07-02
Writing The Agile Manifesto
In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods. We decide to use the term agile to describe this new breed of agile methods. We also wrote the Manifesto for Agile Software Development , setting out the values and principles of these agile processes. I was one of these self-elected visionaries and have since come across many questions about this group's origins and the subsequent founding of the agile alliance. This is my recollection of those events.
Latest Significant Version: 2006-07-09
The Manifesto for Agile Software Development
A group of seventeen people got together in Snowbird, UT in February 2001 to talk about new styles of lightweight methods. One result of this is coining the word agile to represent a new breed of agile processes for software development. We also put together a Manifesto for Agile Software Development which describes the values and principles of these agile methods. Jim Highsmith and I wrote this article for Software Development magazine to further explain the manifesto.
Planning and Running an XP Iteration (by Cara Taber and Martin Fowler)
Since the begining of the new millenium, we've been running an interesting XP project. It's interesting not just because it was one of the first XP projects at ThoughtWorks, but also due to its size: around 50 people are involved. Here we talk about how we run this project by focusing around the activities that need to be done for a single iteration, and how the various subteams work around that iteration.
Variations on a Theme of XP
One of the attractive things about XP is that it gives quite definite statements about what you should do to be doing XP. Furthermore that set of practices is carefully designed to fit together. Taking anything out has serious consequences. Yet one of the principles of XP and other agile methods is that they be self adaptive: that is you should change the process as you are developing the project. How does this notion fit in with the rigid practices of XP?
Latest Significant Version: January 2001
Keeping Software Soft
At Software Development East in 2000, I gave a keynote "Keeping Software Soft". The covered similar material to the original form of my New Methodology essay. As such it's an early description of what was later called Agile methods (the talk predated the Snowbird meeting). Dr Dobbs made the talk available in video and audio feeds. (last time I checked the underlying links were broken.)
Is Design Dead?
For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as "Big Up Front Design", but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.
Latest Significant Version: May 2004
The XP 2000 Conference (with Jack Bolles)
In late June over a hundred people gathered on the Mediterranean island of Sardinia to take part in the XP2000 conference to discuss Extreme Programming (XP) and other flexible methodologies.
Latest Significant Version: 7 July 2000
Continuous Integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
Latest Significant Version: 2006-05-01
Continuous Integration with Visual C++ and COM (by William E. Caputo and Oren Miller)
The Continuous Integration principles are applicable in many different development environments. While the principles remain largely unchanged from project to project, the implementation of this practice can vary considerably. Variables such as language, platform, team size & team location provide unique implementation challenges. Here we will outline how we've implemented CI in a COM/Windows environment for a project developing primarily in Visual C++.
Keeping Software Soft
Why we need methods that assume software should be soft and open to change.
The Almighty Thud
Why you shouldn't write a lot of documentation. Japanese Translation
Agile at 10
SD Times interview on 10 years since the agile manifesto

Columns for Distributed Computing

In the late 90's I wrote the "Methods in Practice" column for Distributed Computing Magazine. Consider whether these are the reasons that the magazine is no longer with us....

Keeping Software Soft
Why we need methods that assume software should be soft and open to change.
Use and Abuse Cases
Ways in which to go badly wrong with Use Cases.
Is there such a thing as Object Oriented Analysis?
My thoughts on the role of analysis in OO projects..
Testing Methods: The Ugly Duckling
Why testing is much more important than most methodologists realize..
What's a Model For?
What is the point of drawing up UML Models?
Refactoring: Doing Design After the Program Runs
A short introduction to Refactoring.
The Almighty Thud
Why you shouldn't write a lot of documentation. Japanese Translation
How Standard is Standard UML?
What does it mean to have a standard UML, and why the standard doesn't standardize as many things as people think it does..

Refactoring

Refactoring Home Page

You can find all my material on refactoring on the refactoring home page

Refactoring Home Page
Articles on refactoring, links to more articles (and tools) on refactoring, index of all the refactorings in the book with additional comments and a few more refactorings..
Crossing Refactoring's Rubicon
In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support
Latest Significant Version: February 2001

Supplements for UML Distilled

Some additional material that builds on what I wrote for UML Distilled

Errata for UML Distilled
Errata for the second edition of UML Distilled
Defining the UML Kernel
At UML World in 2000 we had a panel discussion on whether we should have a kernel for the UML. SD Magazine turned it into a surprisingly coherent article (there's nothing like a good editor!) Take a look to see how frighteningly small I would make the kernel.
Changes in UML Versions
Changes in the various versions of the UML
Application Facades
Analysis Patterns talked about the topic of application facades. This article gives a much more in depth treatment of this idea, including a lot of sample code to help you implement it. This is also an extension of the Java example I gave in chapter 11 of UML Distilled.

Columns for IEEE Software

From 2001-2005 I edited a column on design for IEEE Software.

Enterprise Architects Join the Team (by Rebecca Parsons)
Enterprise Architecture groups often get separated from day to day development. This can lead to their knowledge of development work getting out of date and development teams not taking a broad company-wide perspective. Having seen this happen frequently Rebecca argues that enterprise architects can be much more effective by joining development teams.
Design to Accommodate Change (by Dave Thomas)
Table driven techniques to allow systems to change without major code changes.
Your Coffee Shop Does Not Use Two-Phase Commit
Baristas don't do synchronous processing - their reasons may be reasons for you to go asynchronous too.
Before Clarity (by Michael Feathers)
Clear code is good, but should you sacrifice clarity for testability?
Fail Fast (by Jim Shore)
If software's going to go south, Jim explains in this column why it should collapse as fast as possible.
The Most Important Design Guideline? (by Scott Meyers)
Everyone has their own list of important design guidelines. Scott concentrates on interfaces and how to design them so they are easy to use correctly and hard to use incorrectly.
MDA: Revenge of the Modelers or UML Utopia? (by Dave Thomas)
At OOPSLA 2003 Dave Thomas (the founder of OTI) gave a thoughtful and powerful critique of Model Driven Architecture. In this column he explains why he thinks a universal model-driven approach is likely to fail, and points out that the UML and Domain Specific Languages still have value.
Continuous Design (by Jim Shore)
The rising popularity of refactoring, tools such as JUnit, and agile methodologies such as Extreme Programming (XP) has brought a new style of design into view. Continuous design is the process of using refactoring to continuously improve a program's design. In this column Jim discusses his experiences with continuous design, in particular with design issues that seem tricky such as internationalization and transactions.
Data Access Routines
A common part of encapsulation, particularly with object-oriented systems, is hiding data structures. Yet it's also common to expose much of this data behind data access routines. In this column I cover some guidelines for writing data access routines. However don't forget that if you can leave the data hidden, that's usually better.
Who Needs an Architect?
What is architecture, and who exactly is an architect? These are questions that seem to get everyone very heated. So in this IEEE Software column, I let Ralph Johnson explain about architecture: with a definition that matches all others in a way that nobody agrees with. I also talk about two sub-species of architect: Architectus Reloadus and Architectus Oryzus.
The Difference between Marketecture and Tarchitecture (by Luke Hohmann)
When we think about software architecture, we usually think about its technical architecture. But there's also another important architecture - the one we use to communicate with the customers of the software: the marketing architecture. Neglecting this "marketecture", and its relationship with the "tarchitecture", can get development projects into a lot of trouble.
Components and the World of Chaos (by Rebecca Parsons)
Why chaos theory suggests that component assembly may not be as easy as it's cracked up to be.
Patterns
My IEEE column on the valuable contributions that patterns can make to understanding software design.
When to Make a Type
Guidelines on when to make a new user defined type (or class) for values.
Using Metadata
You can use metadata based approaches to remove the pain from tedious data oriented tasks.
How .NET's Custom Attributes Affect Design (by James Newkirk and Alexei Vorontsov)
Jim and Alexei took a leading role in developing a new version of NUnit. From this they reflected on how design is affected by the new .NET language feature of attributes.
Yet Another Optimization Article
It always surprises me that many well-established principles about performance optimization aren't very well known. This article is yet another attempt to cover these.
Public versus Published Interfaces
Many modern languages make a distinction between public and private features in a module. A distinction that doesn't get made so often is between public and published features: and that may be a more important distinction.
Avoiding Repetition
It's sometimes quite remarkable how the simple rule of avoiding repetition in software can lead into good design
Separating User Interface Code
One of the first lessons I learned was to always keep user interface code separate from anything else. Not just is this still good advice, it's surprising how often it's forgotten.
Protected Variation: The Importance of Being Closed (by Craig Larman)
Craig's spot in the column looks at the importance of the Open-Closed principle and Protected Variation, and why Parnas's information hiding is more than encapsulation. He also gives some tips on ways to implement a protected variation.
Reducing Coupling
Thinking about how to visualize and reduce coupling.
To Be Explicit
Often designs techniques are used to make a system more flexible, but end up being harder to work with. One of the reasons is that explicitness is a property that often gets forgotten in design.
The Test Bus Imperative (by Robert Martin)
Testability is such an important virtue that you should make architectural decisions to improve the testability of a system.
Module Assembly
Modular programming is not just about programming to interfaces, it's also about assembling modules together without the various modules knowing which concrete modules they are talking to.
Modeling with a Sense of Purpose (by John Daniels)
The kinds of model you draw depends on the purpose that you want to put them to. John describes a useful distinction between conceptual, specification, and implementation models.

All these IEEE Software articles are copyright IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Others

The section for papers that don't fit anywhere else.

Ruby at ThoughtWorks
ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a viable platform that should be seriously considered for many forms of applications - in particular web applications using Ruby on Rails. I also go through some technical lessons, including some thoughts on testing with Active Record.
Latest Significant Version: 2009-06-11 16:57 EDT
Writing Software Patterns
I've spent a lot of my writing energy writing patterns. From time to time I get asked questions about why I do that and what makes a good pattern. This is a brief article about how I look at patterns with my suggestions for people who are interested in writing patterns themselves.
Latest Significant Version: 2006-08-01
Using the Rake Build Language
Rake is a build language, similar in purpose to make and ant. Like make and ant it's a Domain Specific Language, unlike those two it's an internal DSL programmed in the Ruby language. In this article I introduce rake and describe some interesting things that came out of my use of rake to build this web site: dependency models, synthesized tasks, custom build routines and debugging the build script.
Latest Significant Version: 2005-08-10
Interview with Artima.com
I was interviewed by Bill Venners for his artima.com web site. In the interview I touch upon refactoring, evolutionary design, flexibility, and test driven development. Bill even manages to make me sound coherent.
Reflection vs Code Generation (by Mike Rettig with Martin Fowler)
Written and thought out very ably by my colleague Mike Rettig. I helped a bit along the way and he was kind enough to credit me. The article talks about techniques for eliminating repetitive code using reflection or code generation and talks about the advantages and disadvantages of each approach. "Developers try to avoid tedious, redundant programming at all costs. Solid coding principles such as inheritance, polymorphism, and design patterns help developers avoid code redundancy. But in the uncertain realm of software development, these principles cannot eliminate the need for code maintenance and rewrites. To a large extent, maintenance is unavoidable, and attempts to create software that never requires maintenance only results in software guaranteed never to work. However, this article shows that you can use the power of Java's Reflection API to reduce tedious code writing, and use active code generation to overcome reflection limitations."
Enterprise Transforming Projects That Don't Kill the Enterprise
This article is based on a talk I gave at LOMA, an insurance industry conference, in 2001. In it I examine a few software development projects that ThoughtWorks has done which are, to some degree "enterprise transforming". The talk (and paper) are aimed at a non-technical audience. From the projects I draw out some common lessons learned. In essence these are: Deliver Frequently, Expect Surprises, Get High Level Executive Support, Treat Business and Software Development as Partners, Choose Technology for the Future, People are The Critical Success Factor, and Keep Learning. A version of this article was recently published in Resource magazine.
Latest Significant Version: 2002-07-02
Writing with XML
For quite a while now, I've been doing most of my writing using XML - even to the point of writing my last book in XML. As I've mentioned this to people they've asked me a number of questions about my experiences, and that's been enough to prompt this little article on the whole thing.
Latest Significant Version: January 2003
Software and Obama's Victory
Barack Obama's victory in the 2008 Presidential campaign included a significant contribution from software - particularly using the Internet. But perhaps the most interesting aspect was the interplay between advances in software and developments in the human organization of the campaign.
Latest Significant Version: 2009-07-30 14:59 EDT
Eradicating Non-Determinism in Tests
An automated regression suite can play a vital role on a software project, valuable both for reducing defects in production and essential for evolutionary design. In talking with development teams I've often heard about the problem of non-deterministic tests - tests that sometimes pass and sometimes fail. Left uncontrolled, non-deterministic tests can completely destroy the value of an automated regression suite. In this article I outline how to deal with non-deterministic tests. Initially quarantine helps to reduce their damage to other tests, but you still have to fix them soon. Therefore I discuss treatments for the common causes for non-determinism: lack of isolation, asynchronous behavior, remote services, time, and resource leaks.
Latest Significant Version: 2011-04-14 09:18 EDT
Musings on Ebooks
It's only just over a year since I got my first ebook reader. Now I only buy paper books when I really have to. I wrote my last book thinking of it primarily as a paper book, but that will be the last time, in the future electronic forms will be at the front of my mind. These changes will completely alter the landscape of books, but other than that, the next steps aren't that clear.
Latest Significant Version: 2011-05-05 09:17 EDT