
Design to Accommodate Change
Table driven techniques to allow systems to change without major code changes.
The best problem-solving writing in software engineering — databases, performance, security, frontend and distributed systems, in one feed.

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

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.

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.