186 articles from Martin Fowler.
Modern source-control systems provide powerful tools that make it easy to create branches in source code. But eventually these branches have to be merged back together, and many teams spend an inordinate amount of time coping with their tangled thicket of branches. There are several patterns that can allow teams to use branching effectively, concentrating around integrating the work of multiple de
In this article I walk through a set of refactorings from a real code base. This is not intended to demonstrate perfection, but it does represent reality.
Get good audio, use gallery view, mute if not talking, and welcome the cat.
A second post on how Thoughtworks is coping with the Coronavirus Disease 2019 (Covid-19) outbreak
We, and our colleagues, are often called on to perform architectural assessments for our clients. When we do this, the architects involved with these systems will talk about the performance of these systems, how resilient they are to faults, and how they are designed to evolve to easily support new capabilities. The elephant that rarely comes up, however, is how different systems contribute to bus
What we've learned so far from dealing with the Coronavirus Disease 2019 (Covid-19) outbreak
When customer companies buy software products, they usually need skilled staff to install them. This staff is usually provided by a service provider company, since software product vendors don't find it makes business sense to build their own services arm. Customers need to be aware of the relationship between product vendors and service providers, and should require transparency on the relationsh
In their ideal state, product-mode organizations are formed of loosely coupled, autonomous teams that respond rapidly to articulated and unarticulated user needs. On occasion however, opportunities arise that require a response involving coordination across multiple teams. If not managed effectively the outcome will result in missed revenue, unsatisfied customers and wasted team capacity. We refer
Many people who work in software development today have heard of the practice of pair programming, yet it still only has patchy adoption in the industry. One reason for its varying acceptance is that its benefits are not immediately obvious, it pays off more in the medium- and long-term. And it's also not as simple as “two people working at a single computer”, so many dismiss it quickly when it fe
Over the last decade we've developed and refined 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 wo
In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support
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 softw
Why we need methods that assume software should be soft and open to change.
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.
The microservice architectural pattern is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management
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.
You can use metadata based approaches to remove the pain from tedious data oriented tasks.
Guidelines on when to make a new user defined type (or class) for values.
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.
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.
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.
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 mainta
It’s hard enough for software developers to write code that works on their machine. But even when that’s done, there’s a long journey from there to software that’s producing value - since software only produces value when it’s in production. he essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Cont
Why you shouldn't write a lot of documentation.
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 my colleague (Thoughtworks CTO) Rebecca argues that enterprise architects can be much more effective by joining development teams.
Ways in which to go badly wrong with Use Cases.
My thoughts on the role of analysis in OO projects..
Why testing is much more important than most methodologists realize..
What is the point of drawing up UML Models?
A short introduction to Refactoring.
What does it mean to have a standard UML, and why the standard doesn't standardize as many things as people think it does..
Table driven techniques to allow systems to change without major code changes.
Baristas don't do synchronous processing - their reasons may be reasons for you to go asynchronous too.
Clear code is good, but should you sacrifice clarity for testability?
If software's going to go south, Jim explains in this column why it should collapse as fast as possible.
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.
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.
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 internationali
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.
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 .
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.
Why chaos theory suggests that component assembly may not be as easy as it's cracked up to be.
My IEEE column on the valuable contributions that patterns can make to understanding software design.
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.
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.
It's sometimes quite remarkable how the simple rule of avoiding repetition in software can lead into good design
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.
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.
Thinking about how to visualize and reduce coupling.
Testability is such an important virtue that you should make architectural decisions to improve the testability of a system.
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.
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.
Generative AI and particularly LLMs (Large Language Models) have exploded into the public consciousness. Like many software developers Birgitta is intrigued by the possibilities, but unsure what exactly it will mean for our profession in the long run. She has taken on a role in Thoughtworks to coordinate our work on how this technology will affect software delivery practices. On this page she post