Reversibility

Introduction

Suppose you are building a treehouse.   Your dad has just gone to get you a pane of glass from the hardware store.   You are left to make the window frame while he's gone.   When he returns you realize that the pane of glass is too big for your window frame.

This is a lesson in reversibility.   What you should have done was make the window frame adjustable so it could fit any size glass pane that your father brought back.   This of course is a hypothetical situation, but a situation like this could happen at work.

This could be a feasible scenario at work:

You: You said we were going to use database M!   We're 80% done with coding, we can't switch now!"

Your Boss: "Sorry, the firm had to standardize on database N instead.   We'll have to recode.   I'll see you on the weekend."

If you had abstracted the database from your code, you could easily have made the change from database M to database N.

Any situation, especially in code, can change as a project progresses.   You may even see that a new route would be a better choice.   If you prepare for these changes beforehand, you could save yourself a lot of time later.

Concepts of Reversibility

Question to Ponder

Suppose there is a room with a dog and a cat in it.   In some cases you could open the door to find the dog and cat tearing each other apart.   In others, the dog and cat may have become friends and be sleeping peacefully.   You only know which case you have when you open the door.

When you are coding for a project, each decision you are making is like opening a door with a cat and a dog inside.   Each decision can result in a different version of the future.   Can your code support the many possibilities the future may hold?   Which scenarios are more likely and how hard will it be to support them if they arise?

Are you brave enough to open the door?