Responsive Design Examples

I'd read about Kent Beck's ideas on Responsive Design and went to Sweden to attend his one-day workshop.

In April 2010 I spent a week with a team refactoring and extending some functionality. Here are some examples of how the Responsive Design ideas look to me in practice.

First, Coupling and Cohesion. A change I made was criticised for making one set of classes aware of an area of the system that previously they'd been independent of. It was a data wrapper area, where all classes provided a similar depth of function. I introduced a specific behaviour to one class to do with the particular Configurable Export function.

That change increased the coupling, and therefore decreased the cohesion of the original classes. To preserve the cohesion we implemented the same functionality in a different way which left the data wrapper classes intact.

Next I looked for examples of Kent's four styles of change.

A Leap example came in replacing variables that were over keen on the use of generics. Specifically the declaration of such variable was

Dictionary<string, Dictionary<string, 
List<string, Dictionary<string, string>>>> x;

I could see that we should replace such variables with a new named class, and replace the accessing of the dictionaries and lists with named functions. But I could not see either how to do that in small steps, nor could I see what names to give to the access functions. It was just a leap. The system was broken until the compile errors went away, but then all worked nicely. I then renamed a couple of functions once I'd seen their use and I was done.

The Parallel change I made concerned code which was in the wrong place, making a class way too big. It was not clear to me what set of functions should be moved out, so I created a Helper class and just moved things that looked right from their function signatures and use of class variables. I disabled the functionality in the original class rather than deleting it at this stage. Once I had something that looked better, I got input from the team about whether it was an improvement and what to call the class. Only when everyone was happy did I remove the obsolete functionality from the original class.

The Stepping Stone change was a classic refactor where an enormous class just had to be broken down and simplified. At least we had good tests around it. The crucial insight here was to convince my programming partner that the changes together would result in a complete change. To start with he was daunted by the scale of the task with its three hundred line functions and enormous switch statements. Kent's Power Point slide for Stepping Stones showed the start of a way across a river. The important point is that you can reach the opposite bank.

The Simplification change came when we wanted to write an update screen for all the configuration data involved in the process. We had editable data grids, but didn't have an easy way of maintaining parent-child links across newly inserted data rows. But we realised that just changing text values would be helpful - not letting the user add rows or affect relationships, just literally letting them change USD to U.S.Dollars. We made that change, stopped, agreed that it was worthy of being released.

Was this Responsive Design? For me, the changes felt like the kinds of refactor I've been doing for ages. It's helpful to think of them in the four forms, because each form suggests its own way of reassuring doubters. Perhaps it would have felt like Design if the system was larger, and therefore a "similarity at different levels" argument means that these are helpful, if small, examples.