I read this Twitter thread with interest/dismay/curiosity at various times. The point is words have power and people need to be cognizant of how they use language. It’s focus is that language exerts the power to exclude.

In this case, the use of “craftsman” is asserted as exclusionary to women. To disagree requires some creativity. Or insensitivity.

You can understand this as follows.

If you relate to being a male but won’t refer to yourself as a craftswoman then you get it.

It’s an excellent point and worth remembering.

It would take considerable effort to understand everything else in this and related threads. I won’t try.

I still follow Sarah Mei. Can’t say I agree with everything she says.

I can say the same about Robert Martin.

I’ll continue to follow them both because I still have hope I can learn from them. Perhaps that’s enough.

A week on and this thread is still going. One argument that’s come up a couple of times is that Sarah is a troll. I think it patiently ridiculous.

She isn’t a troll because she isn’t doing this anonymously. Read her blog. There is a consistent message there.

A better summary of Sarah’s points: More on why agile / XP so often fails heterogenous teams.

I get the pair programming issue–I haven’t seen it work whenever its been forced and I don’t force it.

I don’t get the issue with TDD Test-Driven Development. I treat TDD as a tool in the testing toolbox–use it if you like but you must test your code.

Perhaps the difference here is the 100% component of the argument? Nah, the focus is on the power dynamics.

So where is the power dynamic in TDD? I always thought of TDD as a single person activity which is probably the gap in my understanding.

I wrote the original version of this post in 2018.

Only two things have really changed in the past year. Sarah’s points still make sense. Robert’s are harder to rationalize.

Still following both Sarah and Robert.

References:

• structural oppression - provides perspective on a reference Sarah makes
• systemic inequality - provides perspective on a reference Sarah makes
• tone intolerance - provides a defintion on a reference Sarah makes (Sarah uses a different link)
• bad behaviour online - the whole content triggers outrage thing

In The Mythical Man-Month (Worth Reading Again), I describe the value of re-reading this classic essay.

Some people on team are fond of quoting Brook’s statement that “the bearing of a child takes nine months, no matter how many women are assigned the task”. Unfortunately, they use this statement to deflect analysis on a work breakdown to determine the number optimal number of people on their projects. That’s disappointing on many levels.

It’s an example where the wisdom in Brook’s essay is only partially understood or remembered. It impedes the creation of optimal schedules.

Brook’s clearly points out that adding more people to a late project makes it later. He points out that you should resource your schedules so that the number of people equals the number of independent substasks. Then decide if you want to adjust the number of people on the project.

I am disappointed that people don’t seem to read the full extent of his essay. It is worth reading again. And again. Or at least until someone says they’s reached the optimal number of subtasks in a work breakdown.

This article’s title is taken from an article by Jessica Kerr entitled The Origins of Opera and the Future of Programming. Jessica’s article is well worth the read.

I like Jessica’s article for the juxtaposition of team, people, agility and the notion that we learn together. She calls out the notion that team includes community, and that community might extend beyond the people you work with on a daily basis. Your community might be made of a diverse group of people who share a common interest in solving a problem.

A community shares

• process and values,
• priority problems and
• a shorthand for communication.

Communities place an emphasis on building mental models as a form of communication. Or more so, creating an environment wherein sharing mental models is rewarded. Recognizing generativity over personal productivity leads to symmathesy. (Symmathesy involves the notion that together we learn.)

What intrigued me most about the perspective brought in this article was that it shed light on a problem of my own. I’ve been working with my team for several months. I’ve begun looking deeply into my team’s values as a means to improve communication and create a shared understanding.

It’s striking that my search for values has largely produced a void. It’s not that I can’t identify values in other parts of my organization. I’ve been unable to find a values that resonate with me and my perceptions of what the team values.

The notion of symmathesy might be part of the solution.

When I first joined the team, the major challenge they presented was one of learning. Groups of people felt that they weren’t part of a culture of learning. Others didn’t seem to notice.

The underlying problem was the power hierarchy between groups. The people complaining about lack of learning were newer than those that weren’t. This implied there was lots of tribal knowledge but no emphasis on sharing.

We had a poor understanding of our process. This wasn’t new to me but the process appeared “weaponized” in ways that I hadn’t encountered before.

A weaponized process is one where the process is used to shield people from responsibility, or to stiffle others or somehow introduce inequity between teams. I’d been in environments where the process felt weaponized but the challenge here was outside of my experience. The team was focused on following the process without apparent recognition they could do much more to move the business forward.

Another issue was one of shared understanding of the code base. This overlaps with the learning issue identified above, but seemed to go deeper and touch on empowerment. Empowerment in the sense that people didn’t feel like they could own what they didn’t understand.

Changing the values of the team so that generativity is emphasized looks like a good direction. The notion of symmathesy certainly resonates with me and is something I need to think deeply about.

What I see in Jessica’s article is an opportunity to emphasize share learning for the team through the creation of a process that includes specific values. She has, in effect provided new tools for me to use to frame my own challenges with. These tools look powerful.

I had occasion to read Data Abstraction and Hierarchy and was struck by the concept of locality described in the paper. This paper was presented in OOPSLA 87 and it’s focus is on using inheritance to define type heirarchies. It is the source of what became known as the Liskov Substituion Principle.

The notion of locality is enabled by abstraction supported by specification and encapsulation. The specification describes what the abstraction does, but omits any information about how it is implemented. Encapsulation guarantees that modules can be implemented and reimplemented independently. Encapsulation is related to the notion of information hiding described by Parnas.

The paper goes on to discuss the benefits of using abstraction to define type heirarchies. It includes an example of incremental design through the use of refining the type heirarchy as development progresses on the data type.

What’s interesting is that abstraction supported by specification and encapsulation during incremental design can be used to provide a design rationale.

The design rationale describes the decisions made at particular points in the design, and discusses why they were made and what alternatives exist. By maintaining the hierarchy to represent the decisions as they are made over time, we can avoid confusion and be more precise.

This provides insight on how to minimize documentation (specification), capture the evolution of the a design while communicating intent and history.

I run into this problem all the time: new fact, a piece of information, etc. seems relevant. No good place to store it. Bummer.

Sure I use a few tools to store things and they serve me well. The problem goes deeper than storage.

Another problem I run into all the time is that my software team and I learn something wonderful about how to improve our process. There isn’t a good place to store it. Bummer.

Sure the team and I have tools that permit us to create a shared resource. The problem goes deeper than capture.

The notion I apply to these situations is always that of a parking place. A parking place is a term I use to capture the notion that there should be a natural place to store a piece of information. The new information should fit somewhere. If I can find the fit I am comfortable that I’ve parked the information somewhere where it can be found again and provide value. The notion of natural and comfort with a parking place is also called point of use.

The inabilty to place something into my information management frameworks is signals that we might not be able to properly manage it. That’s worrisome.

An example: the team and I recently discovered an anti-pattern in our code base. Someone researched a pattern to remove it. We can introduce the new pattern to correct the problem. Awareness might be enough to eliminate new instances of the anti-pattern. But it might not be.

It’s now a problem of managing lessons learned–to avoid this problem in the future.

This pattern needs to be captured so that it will be top of mind when it could help us the most. It might have a good parking place in our

• on boarding documents,
• code reviews and
• design reviews.

Cool. We are well position to introduce this pattern into processes we use daily. It’s likely we won’t repeat the mistakes that led to the anti-pattern, even if we all “forget”. (But still follow our processes.)

Here’s another example: I have a passing interest in information management. Tools and techniques for ensuring you have access to the information you need on the things you care about. I’ve read two articles: Wrong. The Answer is Definitely “Maybe”. and Building Your Own Memex (http://www.gradhacker.org/2012/10/10/building-your-own-memex/).

The first is an exploration in a challenge on growing a business; the second discusses a tool used for information management. I don’t have anywhere to park the information from the first article. I have a list I can park information from the second.

In the first case, Getting Things Done provides a clue on what to do with this new information: it’s not actionable, it is worthwhile keeping. That makes it reference material. I need a new parking place. The second is also reference material. I’ve got a list I can add it too.

Someday those references may get a new parking place.

Update: 2020-08-23: The memex article at http://www.gradhacker.org/2012/10/10/building-your-own-memex/ seems to have been removed.