# April 12, 2019

## Using Python's list()

—Using Python's list() function properly.

Got burned by a bug in a Python program. Forgot to copy a list and instead just assigned it a new name.

a = [ 1, 2 ]
b = a
b.pop(0)
b.append(3)
print a==b # Prints True!

print a # Prints [2, 3]
print b # Prints [2, 3]


To create a copy of a, I should have wrote b=list(a).

a = [ 1, 2 ]
b = list(a)
b.pop(0)
b.append(3)
print a==b # Prints False.

print a # Prints [1, 2]
print b # Prints [2, 3]


Bummer.

Found an article that explains this well. Python: copying a list the right way.

# March 14, 2019

## Using Vagrant

—A look at a lesson learned using Vagrant.

I’ve been working with Vagrant for some time.

The value proposition of Vagrant and Packer is that virtual machine builds become consistently reproducible–all of the configuration information is scripted and placed under revision control.

The value of automating virtual machine creation can’t be understated.

My goals for Vagrant involved the creation of a virtual machine cluster that involved two components:

• developer virtual machines (on individual workstations)
• production virtual machines (in a virtual machine cluster)

The developer tool chain would be present on the first and a production image would be exported from the second. Configuration would be shared between the two.

Importantly, our production environment isn’t in the Cloud or a virtual machine cluster. It’s an industrial device. Our device configuration requires the use of specific Ethernet ports, including eth0.

Lesson 1: Vagrant’s reliance reserving eth0 for use by Vagrant turned out to be really difficult to work around in our environment. It became a non-starter for recreating our production environment using a Vagrant generated virtual machine.

Lesson 2: Exporting ISO images from virtual machines is really, really hard. I was able to get it to work through a magic incantation involving mkiofs but it wasn’t trivial to set up. If you aren’t experienced with mkiosfs I’d say you are in for a voyage of discovery.

Lesson 3: The turn around time debugging the configuration is high. I suspect this is why people seem to create their virtual machines interactively then use Vagrant. I wanted to use Packer because it better supported the cradle-to-release of the virtual machine configuration. Unfortunately, builds can take a long time.

In all, I didn’t realize my original goals for Vagrant and Packer. My conclusion is that its an ideal tool for creating virtual machines to deployed in a virtual machine cluster and the Cloud but their are challenges in using it to create images deployed in industrial devices.

Still, not achieving my goals doesn’t diminish my enthusiasm for Vagrant and Packer. I was trying to stretch the use cases for these tools and may have been naive in trying to do so.

I am and do successfully use it to manage virtual machines for constructing test and development environments where those environments remain virtual machines.

# February 19, 2019

## Make a Picture

—Don't get hung up on formality in diagrams.

I’ve written about Ruth Malan’s work elsewhere. I recently come across a tweet she shared:

@ruthmalan:

“making a picture is itself transformational:

1. [..]focused on common goals rather than the things that divide them
2. a co-created picture combines goals, roles and an agreed path [..] literally gets everyone on the same page
3. [..]is a litmus test for feasibility”

– @davegray

Coincidently, I was able to experience this recently with my team. I’d been pushing for more design and facing resistance. On one occasion, I forced a design activity when some team members deemed it unnecessary.

To the team’s credit, they created the diagrams, reviewed them and discovered the requirement could be achieved in a simpler way. Nah, it was deemed unnecessary.

I can’t emphasize enough how the simple act of drawing a picture is transformational.

Interestingly, some team members expressed concern about the quality of the diagram. I’ll emphasize that a photograph of a whiteboard drawing is more than sufficient to achieve understanding.

People are sometimes afraid to express themselves using drawings because of expectations they place on themselves. If your team has trouble putting pen to paper consider whether unstated expectations on format are holding them back. Focus on understanding instead. It’s more valuable.

# February 13, 2019

## Planning Meeting

—Small change in interaction. Big change in opportunity.

The team and I have been struggling with improving several Scrum activities. The planning meeting is one of them. Our struggle focused on how to get more value from the planning meeting.

One team member decided to increase stakeholder engagement by engaging on whether the stories the team was about to commit to were in fact ones that could be completed by the team. The result was astounding.

We initially focused on logistics – are the components in place and operational that permit software development? Basic impediment management. This quickly expanded into a run through of our ability to test the story.

I’m actually excited by this development because we are improving interaction with the stakeholders and it’s a benefit to everyone.

# January 21, 2019

## Changing Defect Management to include Root Cause

—Root cause analysis for defects is critical for improving your process.

I’m in the process of changing defect management in my team. We use our retrospective to review defect and cost overruns during the sprint.

The change I’m making incorporates two ideas:

1. every defect is a lifecycle issue, and

The first idea ensures the retrospective remains a safe place to acknowledge errors. This is important because the errors that prompted the defect could be the result of an error made by someone at the retrospective. For example, a coding error that escaped code review.

The second idea ensures we focus on root cause and not the defect correction. This is important because the defect is a symptom. First, focusing on the correction would repeat the code review. Second, this sets up the context so that the focus is on what was being attempted when the defect was introduced.

I focus on the code because that’s closer to where the error manifests. Defects manifest as a behavioural or functional issue because something isn’t meeting the expectation of “working”. Since we have a patch for the defect we have a notion of what expected behaviour is. What we don’t know is where the problem entered the lifecycle.

I could focus on the test but it seems obvious we lack a test case otherwise the defect would have been corrected earlier. Clearly, a lifecycle issue that manifests in requirements won’t have a test case…

Since the code is the focus I use the commit history as the starting point.

 R3 <- defect fix applied to great new feature R2 <- another great new feature R1 <- great new feature

The patch applied in R3 might update changes in R2, R1 or both.

What motivated R3 is interesting. What motivated R3 is in R1 or R2 or both.

That is R3 might:

• fix something in R1,
• fix something in R2 that negatively impacted R1, or
• fix something affecting both R1 and R2.

The problem gets complicated when there are many revisions affected by the defect fix. Such situations will bring in multiple people and perspectives. And hopefully ways to mitigate recurrence.