Preface

 

We once worked on an application that was used to configure the behavior of a specialized electronics module in an expensive hardware product. Our application was a part of the delivery of that product. One day, news reached our software development team that Sales had unexpectedly landed a contract with a new client. At first we didn’t know what to make of it, but in time we learned that the new client needed a version of our application that was almost identical to the one we had. This was fortunate. But after further investigation, we realized that there were certain parts of the application code that under no circumstances could be shared between the new client and our old ones. We had to come up with a solution to this problem, or we couldn’t deliver to the new client at all.

It finally boiled down to two possible solutions. We could duplicate the whole application, or we could restructure first and break out the parts that couldn’t be shared. Our team argued for well over a week before we reached consensus. We decided that the best solution was the restructuring approach: restructure first, and then add the new functionality. This shouldn’t take more than a month, or maybe two, we thought to ourselves.

Brownfield Development

The Goal: Morphing a System

The Mikado Method

The Name of the Method

Characteristics

A Thinking Tool

sitemap