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 rapidly growing interest in agile
(aka "lightweight") methodologies. 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. I also give a summary and references to the
processes in this school and consider the factors that should influence your
choice of whether to go down this newly trodden path.
- Latest Significant Version: April 2003
- 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: February 2001
- Continuous
Integration (with Matt Foemmel)
- An important part of any software development process is getting reliable
builds of the software. Despite it's importance, we are often surprised when
this isn't done. Here we discuss the process that Matt has put into place on a
major project at ThoughtWorks, a process that is increasingly used throughout
the company. It stresses a fully automated and reproducible build, including
testing, that runs many times a day. This allows each developer to integrate
daily thus reducing integration problems.
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.
- Developing
Patterns of Enterprise Software
- A short page on the growing community and body of work in capturing
patterns for the development of enterprise applications.
- Latest Significant Version: May 2003
- 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
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.
- New Analysis
Patterns
- I've returned to writing about Analysis Patterns and this will probably
lead to a new book in the hopefully near future. As I work towards it, this is
the place where I'll post my work in progress.
- 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.
- The New
Methodology
- In the past few years there's been a rapidly growing interest in agile
(aka "lightweight") methodologies. 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. I also give a summary and references to the
processes in this school and consider the factors that should influence your
choice of whether to go down this newly trodden path.
- Latest Significant Version: April 2003
Using an Agile
Software Process with Offshore Development
- For the last two 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: September 2003
- 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.
- The Agile
Manifesto: where it came from and where it may go
- 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 future. This essay
describes my opinion about the answers.
- Latest Significant Version: February 2002
- 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 (with Cara Taber)
- 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.
- Latest Significant Version: January 2001
- 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 light 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?
-
-
- 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: February 2001
- 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.
- Continuous
Integration (with Matt Foemmel)
- An important part of any software development process is getting reliable
builds of the software. Despite it's importance, we are often surprised when
this isn't done. Here we discuss the process that Matt has put into place on a
major project at ThoughtWorks, a process that is increasingly used throughout
the company. It stresses a fully automated and reproducible build, including
testing, that runs many times a day. This allows each developer to integrate
daily thus reducing integration problems.
- 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++.
- Quick Page on XP
- A short summary of XP with links to where you can find the real meat..
- 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.
- Keynote
at SD East
- At Software Development East in 2000, I gave a keynote "Keeping Software
Soft", which covers very similar material to my essay The New
Methodology. Dr Dobbs magazine made the doubtful decision to tape this and
offer it as a webcast. This way you get to see a very small shaky picture of
me umming and erring. Isn't technology wonderful?
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.
- 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
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
At the beginning of 2001 I started to edit a column on design for IEEE Software.
- 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.
- 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.
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.
- 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.
- 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
|
 |
© Copyright Martin Fowler, all
rights reserved