The Holy Java

Building the right thing, building it right, fast

Parallel Design (Parallel Change)

Parallel design means that when changing a design, you keep the old design as long as possible while gradually adding the new one and then you gradually switching to the new design. Only after that you gradually remove all the old code.

This applies both at large and also (surprisingly) small scale. Though it costs you more – you have to figure out how to have them both run and it requires more effort to have them both – it often pays off because it’s safer and it enables resumable refactoring.

An example of a high-level parallel design is the replacement of a RDBMS with a NoSQL database. You’d start by implementing the code for writing into the new DB, then you would use it and write both to the old and the new one, then you would start also reading from the new one (perhaps comparing the results to the old code to verify their correctness) while still using the old DB’s data. Next you would start actually using the NoSQL DB’s data, while still writing to/reading from the old DB (so that you could easily switch back). Only when the new DB proves itself would you gradually remove the old DB.

An example of a micro-level parallel design is the replacement of method parameters (message etc.) with the object they come from (an Edge), as we did for notifyComment:

- public void notifyComment(String message, String eventName, String user) {
-    notifications.add(user + ": commented on " + eventName + " " + message);
---
+ public void notifyComment(Edge target) {
+    notifications.add(target.getTo().getId() + ": commented on " + target.getFrom().getId() + " " + target.get("comment"));

The steps were:

  1. Adding the Edge as another parameter (Refactor – Change Method Signature)
  2. Replacing one by one usages of the original parameters with properties of the target Edge (Infinitest running tests automatically after each change to verify we’re still good)
  3. Finally removing all the original parameters (Refactor – Change Method Signature)

The good thing is that your code always works and you can commit or stop at any time.

Related

Parallel Design enables Resumable Refactoring – the code is always buildable and you are able to stop in the middle of the refactoring and continue (or not) at any later time.

References

  • ParallelChange at MartinFowler.com by D. Sato – break the change into expand, migrate, and contract; nice examples and useful links
  • Joshua Kerievsky’s talk The Limited Red Society – the author argues for keeping periods when code doesn’t compile or tests fail to minimum and shows examples of Big Leap and Parallel Change (referred to as Paralle Design here) strategies; highly recommended
  • Summary of Kent Beck’s talk Best Practices for Software Design with Low Feature Latency and High Throughput
  • Kent Beck’s presentation Effective Design (slides 8 and 9)
  • The Succession entry in Kent Beck’s Software Design Glossary – “[..] Succession is the art of taking a single conceptual change, breaking it into safe steps, and then finding an order for those steps that optimizes safety, feedback, and efficiency. [..]”
  • Dan Milstein: How To Survive a Ground-Up Rewrite Without Losing Your Sanity – quotes: “Over my career, I’ve come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces.” And: “Here’s what I’m going to say: always insert that dual-write layer. Always. It’s a minor, generally somewhat fixed cost that buys you an incredible amount of insurance. It allows you, as we did above, to gradually switch over from one system to another. It allows you to back out at any time if you discover major problems with the way the data was migrated (which you will, over and over again). It means your migration of data can take a week, and that’s not a problem, because you don’t have to freeze writes to both systems during that time. And, as a bonus, it surfaces a bunch of those weird situations where “other” systems are writing directly to your old database.”

3 Responses to “Parallel Design (Parallel Change)”

  1. […] Parallel Design: Sometimes a change cannot be really broken down, such as replacing a data storage with another one. In such a case we can apply for example the Parallel Design technique, i.e. evolving the new code, while still keeping the old code around. We can, for instance, first write only the code to store data in the new database; then start also reading from it while also reading from the old database, verifying the results are same and returning the old one; then we can start returning the new results (still keeping the old code around to be able to switch back); finally we can phase out the old code and storage. […]

  2. […] Parallel Design: Sometimes a change cannot be really broken down, such as replacing a data storage with another one. In such a case we can apply for example the Parallel Design technique, i.e. evolving the new code, while still keeping the old code around. We can, for instance, first write only the code to store data in the new database; then start also reading from it while also reading from the old database, verifying the results are same and returning the old one; then we can start returning the new results (still keeping the old code around to be able to switch back); finally we can phase out the old code and storage. […]

  3. […] stepwise deployment: Use parallel change and other Continuous Delivery techniques to make it possible to deploy updated components […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: