Coping with Covid-19, part 2
A second post on how Thoughtworks is coping with the Coronavirus Disease 2019 (Covid-19) outbreak
Coping with Covid-19
What we've learned so far from dealing with the Coronavirus Disease 2019 (Covid-19) outbreak
Product-Service Partnerships
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
Outcome Over Output
Crossing Refactoring's Rubicon
In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support
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 softw
Keeping Software Soft
Why we need methods that assume software should be soft and open to change.
Microservices Guide
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
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.
Using Metadata
You can use metadata based approaches to remove the pain from tedious data oriented tasks.
When to Make a Type
Guidelines on when to make a new user defined type (or class) for values.
The XP 2000 Conference
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.
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.
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.
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 mainta
Continuous Delivery Guide
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
The Almighty Thud
Why you shouldn't write a lot of documentation.
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.
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..
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 .
Patterns
My IEEE column on the valuable contributions that patterns can make to understanding software design.
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.
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.
Reducing Coupling
Thinking about how to visualize and reduce coupling.
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.
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.
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.
UML Diagrams for Analysis Patterns
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
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 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.