Wednesday, September 30, 2015

Crossing your technical road

Dinesh and David are good friends and good programmers who live in Delhi and Dallas, respectively.  

For reasons that defy explanation to non-programmers, they were recently on Skype and having a (good-natured) argument about how to cross a busy road.  “I’m not sure what’s so hard,” said David, “Just get to the curb, look both ways, wait for a break in traffic, and then go."

“What do you mean about waiting for a break in traffic?” asked Dinesh.

“You know, wait for an opening in the traffic on the road when there’s no one coming."

“No… one… coming,” asked Dinesh in a confused manner.  “Like no one at all?"

“Right,” said David.

“And what wee hour of the morning are you crossing?” asked Dinesh.

“Not a wee hour,” said David, “Just any time.  OK, you might need to wait for the timing of the stoplights to hold all the traffic."

“Stoplights that hold all the traffic?” Dinesh’s face had taken on a look of full incomprehension, noticeable even in the small Skype window.

“Yes, depending on the synchronization and position of the stoplights,” said David.

Dinesh’s Incomprehension had given way to a glimmer of amusement.  David ignored the look from his friend and continued.
 
 “Yeah, you just wait for a break in traffic and then go.”  He paused a beat and added, almost as an afterthought, "Depending on traffic and the width of the road, you’ll probably need to run."

“Run?  Are you serious?” This was now too much for Dinesh, whose arms were extended in a gesture of exasperation.  “That’s way too dangerous.  Running will get you killed."

This earned a raised eyebrow from David who seemed to secretly enjoy riling up Dinesh.  “What would you suggest?,” he asked with a barely concealed smirk.  “Should I walk across the road?"

“Precisely,” said Dinesh in a profound and sincere manner..

“Do tell!” said David, whose face now held a full grin as he awaited his friend’s explanation of the seemingly inexplicable.

Dinesh took a breath and began.  “Get to the curb, look in the direction of closest oncoming traffic, taking into account one-way streets, of course.  Then when there is a small break, or when traffic is stopped, step off the curb and work to cross the first line of traffic…"

“Lane, “ said David, a little too abruptly (he sometimes badgered Dinesh about his accent).

“No, line, I pronounced it correctly my drawling Texas friend.  Work to cross the first line of traffic.  You may have to catch the eye of the oncoming driver to make them slow down a bit to let you clear.  Or you can maybe just show them a hand"

“Um, Dinesh, you don’t mean to give them the finger, do you?” asked David cautiously, who thought his friend to be polite, but wasn’t too sure of his tactics at this point.

“Certainly not!”, exclaimed Dinesh, “I said to show them a hand; just a small low sort-of wave that we do to get their attention.  It is kind of like the gesture that a police officer would perform to say Stop, but this is made very low and close to the body, to as to be as humble as possible.  After all, I am just a pedestrian, the driver is controlling several thousand pounds of car."

“Ok, I think I get it,” said David, who still wasn’t quite sure of this approach, but was relieved that his friends tactics didn’t include obscene gestures.

“Anyway, as you are partway through clearing the first line of traffic, you start looking at the next line, keeping an eye out for motorbikes or scooters, which may be between lines.  You may need to adjust your angle of crossing, heading downstream a little bit, to let a motorbike pass so you can tuck in behind it.”  He continued, as David’s eyes widened.  “Then looking at the next line, just repeat the process again, recognizing the traffic may be changing speeds.  Or there may be an autorick, I mean tuk-tuk, or even a truck, both of which require special care."

“Special care?” wondered David.

“Yes, special care,” replied Dinish, “The little autoricks are quite unpredictable in both speed and direction, while the trucks are simply slow and frequently have poor brakes."

“Wow,” said David, who was having a hard time picturing this process, “are you across yet?"

“No, not at all, after 4 or 5 such encounters, I’m probably about halfway,” said Dinesh.

“Halfway!  Then what?” David wondered.

“Midway I’d stop and wait for a bit, whether there is a raised divide or not, the traffic will just flow around me,” said Dinesh.  “Then I’ll just start out again, handling traffic headed in the opposite direction."

“Wow,” that’s crazy, said David, shaking his head.  “The middle of the road is a dangerous place.  I can’t imagine stopping there."

“Not at all,” smiled Dinesh, "it’s quite safe, you just have to hold still"

“I guess we’re even, or something like that,” said David.  “You can’t run and I can’t walk"

“Correct,” said Dinesh, “And I need to stop in the middle while you can’t stop in the middle"

“You live in a strange world buddy,” said David.

“So do you, my Texas friend, so do you,” said Dinesh.

---

This entirely fictional story (cum parable) emerged from a set of recent discussion with different (Chennai-based) teams about the technical transition that each one faces.   Both teams have challenging transitions and need to carefully choose a transition approach.  And so like David and Dinesh, they need to not only plan carefully and execute well, but the plan needs to match with their context.
 
The first team is approaching particularly difficult UI architecture transition that a product needs to make. Their context included the following:
  • No (apparent) backward or forward compatibility between architectures
  • A large application with rich business functionality
  • A wide variety of highly customized UI controls that had absorbed all varieties of specialized requirements over the years

The current estimates were coming in at levels that were both resource-heavy and for a long period (6-12 months).  The team was considering branching the code and having the work proceed on the branch for the duration of the transition.

Hmm.

But, I asked, wouldn’t this mean that the UI functionality would either be frozen for the migration period or there would be a backlog of changes to merge?  Yes, they agreed.  (Hmm.)

And, I asked, wouldn’t this mean that the even if the UI functionality was frozen, there would be some element of merging happening after we completed the migration effort.  Yes, they agreed again.

And here we stopped and I said that we needed to find a new way to go about the transition because the current migration approach is too slow and gradual and isn’t matched to the context.

In the second case, the particular team is working to find the best approach to allow customers to transition from one product to another.  This transition is made more crucial by the domain (healthcare) where there is very little appetite for operational risk and the system has deep integrations into many other systems.  Therefore, the transition is likely to require considerable testing and verification by the user community before a cutover is implemented to ensue that patient safety is maximized.

Here the team spent time explaining the formidable test plans they had assembled to complete pre-deployment testing.  They included a battery of testing (both automated and manual) for many scenarios. We talked about getting user data (anonymized for privacy concerns) into the test lab.  We discussed various kinds of test case reviews with the user community.  All of the information looked great.  And by most perspectives, the team’s cutover plan looked solid.

But then, at the tail end of the discussion, I asked some questions which brought the room to a halt.   I inquired about:
  • The impact of anonymized data
  • The completeness of data scenarios
  • The completeness of usage scenarios
  • The ability to completely simulate upstream and downstream systems
These team responded that they had awareness of these and had worked to factor them into the testing plan.  But, they said, there were practical limits to their ability to address these.

And so, again as before, we stopped and I said that we needed to find a new way to go about the transition.  But this time, it was because the current transition because the current migration approach is too fast and abrupt and isn’t matched to the context due to patient safety concerns.

These two examples demonstrated the necessity of matching transition approach to operational context.  In the first scenario, the team was considering a long transition period, which would bottle up change and introduce risky merging.  In the second scenario, the team was considering a cut-over approach, which resulted in taking on a level of risk that was mismatch to the domain.  

One team needed to go faster; the second team needed to go slower.

So when planning your transitions, remember to step back and look at your context.  Without this consideration, even the best planned transition will be more difficult than it needs to be... and might not be successful.






No comments: