Nowadays, deliveries are unlikely to be one-shot ones. Even if not explicitly stressed - and even more when it is explicitly stressed that we don’t have to care about - we learned from experience that we should design our software to be ready to tackle next move(s). Some folks are even used to gauge a project according to its sustainability. And here come questions regarding resilience to changes, aka “what if”.
Sarting from the big picture view we introduced in the last post, we can introduce a non-exhaustive list of “what if” use cases.
What if someone asks for a…
…change within a workflow
Like adding an extra stage between 2 existing ones
 |
 |
|---|
Update neighbor stages connection accordingly to introduce brand-new stage
… change within a dedicated stage
Like removing a deprecated section
 |
 |
|---|
Changes are scoped to stage, nothing else to amend
… change within a dedicated section
Like replacing manual interaction with 2 different flagship with equivalent automated process performed by a service
 |
 |
|---|
Changes are scoped to section, nothing else to amend
… change within an underling skills
Like moving from desktop flagship to remote twin.
 |
 |
|---|
Changes are scoped to section and should be narrowed to places where the said flagship is provisioned and decommissioned OR configured.
… change a local rule
Like swapping synchronous call with asynchronous twin, and be triggered with results availability
 |
 |
|---|
Changes are scoped to section and side-effect should be kept under control (from sync to async should not lead to a full section rewrite)
… change a global rule
Like cleaning existing output files related to this section if any.
 |
 |
|---|
I’d like to setup rule once, and changes to be spread accordingly. I expect framework/SDK to support this feature.
Closing
It’s important for a team to be able to answer the “what if” question series. Experience advocates to census use cases as they come or as we foresee they will, without waiting for someone else to ask for. Be proactive on this topic, as it may also consolidate or invalidate your current design. Failing fast is one famous adage, that we should probably more evenly follow.
Side notes on the method. Sticking to kid analogy, we leverage thumbnail to materialize and compare changes. As for surgery analogy, we reduce scope of changes to the meaningful boundary, venting neighboring noise and blur. Feel free to mix n’ match analogies to improve your daily work. It’s up to you to find the best cocktail.