September 10, 2019

Great Teams Make Great People

  —Being part of a great team amplifies what people accomplish.

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.

September 4, 2019

Locality and Design Rationale

  —Minimize documentation while simultaneously communicating design intent and history.

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.

August 12, 2019

Parking Places (for Information, Silly)!

  —Managing information more naturally.

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.

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.

August 6, 2019

Characteristics of a Good Design?

  —What characteristics make up a good design?

In What is Good Design (Part 1), I was trying to characterize a good design. My thinking has changed since I wrote that article. I’m trying to view design and architecture as the same thing, but acknowledge that architecture is design that focuses on things that are expensive to change.

Design in this context can be viewed as anything that isn’t architecture (can be changed easily–easier).

It’s a position that has been influenced by a variety of factors. A good starting place is Ruth Malan’s Visual Architecting Keynote. I explore Ruth’s keynote in Documenting Architecture Decisions and Big Ball of Mud.

A key insight in Ruth’s keynote.

We’re holding these two ideas about architecture in creative suspension – architecture is decisions about “the important stuff” where important is distinguished by cost of change, and architecture is about the structure of the system, which has something to do with (lowering) the cost of change.

I like the notion of creative suspension. It provides insight on the difference between architecture and design.

A good architecture seeks to minimize cost of change by managing things that are hard to change. A good design follows the same thought trajectory if that design is dealing with important stuff (e.g., relationships between concepts). A good design follows a different thought trajectory if that design is dealing with encapsulated stuff (e.g., the implementation of a concept).

In What is Design (Part 1), I was searching for a way to frame a direction for my team on what constitutes good design. Recall, in the context of that question I said

This important to help align the team around the objective of improving our designs–how do we know good design when we see it?

At the time, I was seeking a concept that could be articulated as a goal and guidance on knowing if we where headed in the right direction.

Does Ruth’s keynote improve my chance of success here? I think it does. Controlling cost is an architecture issue. Design that isn’t expensive to change is not architecture.

How does Ruth’s keynote improve my chance of success? I still don’t have a notion of good design other than it solves a problem whose constraints and use help define it. I have a good notion of the difference between architecture and design but that pushed the vagueness of these notions into cost. I did solve one problem: architecture and design are the same thing. Just different in terms of diffculty to change (hence cost).

July 14, 2019

Google's International Targeting

  —International targeting for unilingual/multi-regional sites.

This blog is only written in Canadian english (en-ca). This is close enough to english (en) that I’d like it to turn up for anyone looking at english search results. Seems reasonable.

Google’s Search Console flags my site saying

Your site has no hreflang tags.

My country is unlisted because I don’t feel like my topics should be targeted at only Canadian users. Vain perhaps, but reasonable given the english-only content.

My site’s URL is bminard.github.io.

How to add hreflang support to my site to eliminate the problem identified in the Google Search Console.?

From Multi-regional and multilingual sites:

A multi-regional website is one that explicitly targets users in different countries.

My site seems to fit the definition of multi-regional, as I am targeting english speaking users in different countries.

From Use hreflang for language and regional URLs:

Using language annotations

Imagine you have an English language page hosted at http://www.example.com/ … …

  • Sitemap. Instead of using markup, you can submit language version information in a Sitemap.

Expanding your site to more languages provided information that cleared up my confusion. The use of hreflang for unilingual and multi-regional sites started at the 0:6:34 mark: use a sitemap even if your site uses only one language.

An example using Jekyll to generate a sitemap containing hreflang. If you need a simpler example, checkout Use a sitemap to indicate alternate language pages.

I modified this example as follows.