A pleasant walk through computing

Comment for me? Send an email. I might even update the post!

One Sheet Summary: "Accelerate: The Science of Lean Software and DevOps"

I make these to post on my wall and help me learn the subject. Be sure to read the book!


Download the PDF Version

Five (so far) Dynamics of Group Problem Solving

HOW ARE YOUR PROBLEMS BEING SOLVED?

This Post Is

  • My (relatively educated) opinions
  • To get you (and me!) thinking

1. "Do this!"

  • Often (upper) management or overbearing personalities
  • Driven by "I'm supposed to decide." and "my first thought is the right answer."
  • Can be important in urgent or gridlock situations.
  • BUT, mustn't become the go-to.

Mitigation: "We're providing an update, but we're open to ideas."


2. "There are two ways..."

  • Often team leads or developers not directly responsible for the outcome
  • Simplistic to get quick buy-in
  • Driven by "I'm supposed to know" and maintaining status quo
  • Stops exploration and can shortcut testing
  • Flatt's Law #12: "There are usually many right ways to do something, and always infinite wrong ways."

Mitigation: "We'll start with those, and review with you if we come across alternatives."


3. "I’ve already thought of/tried that."

  • Often a senior developer
  • Stops conversation
  • Pits the "expert" against colleagues
  • Leads to gridlock and win-lose thinking
  • Can be ego/image-driven
  • BUT, can also be true

Mitigation: "Can we look at your steps/tests/code? We want to perform due dilligence."


4. "We've already thought of/tried that."

  • Can hide a decision actually made via 1-3.
  • Can be clique-driven
  • BUT, is usually true (i.e., "we're really in agreement")
  • BUT, still potentially stops exploration
  • Can be valuable when presenting to management
  • BUT, requires trust. Can be a cudgel, "you don't really understand what we do."

Mitigation: "I'd like to understand better. Who can step me through what you've done?"


5. "This is where we are right now."

  • Can be used by anyone at any time
  • Growth mindset
  • Psychologically safe
  • "What's been tried? What can we try?"
  • "What's the real problem we should be solving?"
  • "How urgent is it really?"

In General

  • Fast vs Slow thinking: slower is better for solving problems
  • Measures of Success: quality is usually better than speed
  • Habits: Encourage asking questions as the path to solutions.
  • Fixed vs Growth Mindset: start from "I don't have to know right now."

More Reading

Domain-Driven Design - An Opinionated Layers Graphic

The DDD implementations I've seen in tutorials tend to leave out a couple of things.

  1. Applications get domain information two different ways. Javascript frameworks call WebApis. But desktop apps can use the domain services directly, avoiding the performance waste of an extra call. Think of the WebApi as a passthrough (façade) to the domain service.

  2. Domain models <> Data models. The domain layer--critically--takes care of mapping data to domain. Consider that your domain models may be populated from multiple data sources, or multiple tables from a single database . . . or both.

Loosely-Coupled Domain-Driven Design Architecture