Friday, September 22, 2023

Lessons in Change from the Classroom

This is adapted from a story I shared at the Fearless Change Campfire on 22 Sep 2023

I’ve always been someone to ask questions about ideas. Questions about rules for behavior seemed different. I went to high school in New York City in the early 1980s, and there were students around me who wore “Question Authority” buttons. I was not one of them. —Though I think a part of me secretly wanted to be.

As a child I was a rule follower. If a teacher had a rule — unless it was obviously harmful to someone, I wouldn’t even consider breaking it. It’s not that I thought that teachers were infallible; I learned early that teachers sometimes make mistakes and some — not the good ones — don’t admit them (but that’s another story). I just didn’t have a framework to think about rules. Until junior year of high school.

The class was Algebra II and Trigonometry. I did well in the class, and I liked it, in part because the teacher — Ms Yearwood — was an amazing, caring person in addition to being a great teacher. But she was strict. She had Rules.

A few days a year Ms Yearwood, would have laryngitis. On those days she'd sit at her desk, do grading, and drink tea. And the rule was that students sit silently and work on exercises.

On one of these days the person sitting next to me — I think her name was Lisa— asked me for help with a problem. Since I understood the subject and I wanted to help. But there was this Rule. In the end I decided to lean over towards Lisa’s desk to discuss the problem.

Did I mention that our desks were near the front of the classroom? As we were (quietly) talking through the problem Ms Yearwood looked up, turned in our direction, and glared at us. Time seemed to stop.

Then she realized that we were working together on a problem, and not being disruptive. Her expression shifted to a smile and she gave us an encouraging nod.

At that moment I learned a perhaps obvious lesson:

Rules have a purpose and context, and aren't necessarily absolute, or even fully described by their words.

I this case “work quietly” was meant to maintain order and enable learning. There were exceptions to the the rule, in particular when what you were doing served the purpose of learning.

A second lesson was

You can learn important things in unexpected contexts, and in brief moments

This was a math class. I wasn’t expecting to learn a deep moral lesson, and certainly not from an ad-hoc interaction.

This isn’t the only case where what I learned in class transcended the subject matter and helped me in my life and career. — But this story sticks with me because I’ve been able to apply these particular lessons in many aspects of my life including as an employee, colleague, partner, change-agent, and citizen.

I sometimes still give rules the benefit of the doubt. But for all but the most obvious ones, I try to be curious and seek to understand why the rule is there. And I’m highly skeptical anytime I hear the phrase “Zero Tolerance.”

Even with this healthy skepticism of rules and willingness to, analyze, if not question, authority I wonder if we really need to always try to understand the why for every rule before we follow it? Or Are there any universal rules about behavior that don’t have a why worth understanding?

My sense is is that, beneath any rule that seems intuitive there is a purpose that supports something you value. But I try to not fall into complacency. The status quo is comfortable, and easy. And sometimes we need comfort and ease. But growth requires change and change requires curiosity and enough fearlessness to push boundaries when you see a rule that seems arbitrary and is a barrier to doing something valuable.

Tuesday, November 29, 2022

Branching and Integration Time

Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a branch or in a developer’s workspace. Discussions about improving pace of development often veer into arguments about branching. Arguing about whether branches are good or bad will distract you from the more basic question of “Do changes get integrated and tested rapidly enough to ensure the rate of delivery we want?”

Integrating too slowly is the main challenge to agile development. Slow integration makes it harder to show incremental progress and maintain an always working code line with valuable features. Frequent integration helps the team deliver incrementally and maintain working software. Your process should help you to integrate quickly so that you can deliver value at a good pace.

The ideal integration frequency varies from team to team. Merging once a day is good, more frequently can be better, but too often can cause churn and overhead if you aren’t doing it well. Team and planning dynamics are key decision factors, but some things are universally true: small frequent commits improve reliability, changes that move the design forward are more valuable than trivial changes. These factors often lead to once a day as a good initial target, but each team needs to decide what values of “small” and “frequent” work for them. (Retrospectives are a good forum for exploring that question.) Automated testing is essential to moving quickly even though it can add a small increment of time to the commit interval in the short term.

Getting this to work well can be challenging, but it is doable. Small useful increments and effective tests are easier than many believe. Though you may need to change your mindset.

Branches and reviews can improve collaboration for both co-located and remote teams. So rather than starting with a “branch or not” conversation, start with an integration rate goal and evaluate how long it takes code to get into production. The next post will talk about why branching can have advantages for your team.

(This is adapted from an earlier Techwell article)

Sunday, November 20, 2022

Perceived Safety and Branches

Branches are often used with the goal of improving stability. This going wrong is often the source complaints abut the use of branching. This post briefly examines the rationale behind branching some non Main Line branching strategies.

Thursday, November 10, 2022

Workspaces and Delays

A Brief Detour from talking about branching. There are risks with branching, there are other paths that lead to deferred integration, and all the issues that arise from that.

Monday, November 7, 2022

The Trouble with Branching

Code Lines defined terms, Why Code Lines Matter motivated why SCM Process matters, and the post addresses a major risk people see in using branching.

Wednesday, November 2, 2022

Why Code Lines Matter

Code Lines defined some terms. Here I’ll start getting into how SCM and Version Management concepts affect your day to day work

Monday, October 31, 2022

Code Lines

My last post introduced the series. This post defines some terms and sets the stage for discussing the value of simple branching for agile teams

Lessons in Change from the Classroom

This is adapted from a story I shared at the Fearless Change Campfire on 22 Sep 2023 I’ve always been someone to ask questions about id...