Todd Sedano

Software Engineering, Improv, Craft of Software Development

Illusion of Requirements

Title: The illusion of requirements; the requirements myth

“Requirements” is a pre-agile construct based on our false belief that building software was somehow like the construction of buildings.

“Requirements” limits the development team into thinking the end product is fixed and that the team’s goal is to implement a specification.

Agile development teams expect features to change over time. Even with thorough user research and validation, the product will change as soon as we receive user feedback. Even during the implementation of a user story, an emergent conversation on the team might change its acceptance criteria.

In contrast, features are a construct of preferences. Many preferences may stay the same, some will change over time, and most are made up on the spot Lichtenstein and Slovic 2006.

A simple example

Let’s consider a simple and common feature request: “the user logs into the system with a username and password.” If we consider this request to be fixed, we might not consider alternative solutions.

  • Some websites support magic links. You don’t type in a password, the system emails you an authentication link.
  • Some websites require two-factor authentication.
  • Some websites rely on a third-party single sign-on such as Google, Facebook, or Okta.

Several of these solutions also attempt to solve the problem of users creating easy to guess or easy to break passwords.

Treating authentication as a “requirement” misses these opportunities.

System characteristics

How then do we deal with performance, scalability, availability, recoverability?

Pre-agile has the notion of “non-functional requirements” which describe system characteristics or product quality characteristics.


Before agile, I wrote my share of statements like “the web page should load in under 0.5 seconds.” In reflection, my non-functional “requirements” were arbitrary limitations on the system.

Here’s the typical workflow for agile software development. * Conduct user research and validation to determine appropriate feature for the opportunity * Build a minimal implementation of the feature * Verify that the feature matches the opportunity, if not iterate * Improve performance where needed This is a variant of “Make it work, make it right, make it fast.”(

Availability and Recoverability

Many of the system characteristics such as availability can influence Service Level Agreements. Pre-agile treats these as guarantees. If we build the system just right, we can guarantee that we will achieve a particular outcome. Agile treats these as goals. If we want to prove ourselves that the system handles disruptions, then we introduce disruptions much like Netflix Chaos Monkey. We keep iterating on the product and deployment process until we achieve the goal. Adding Chaos Monkey to a system could be considered a “non-functional story” or a chore, since it provides no user facing functionality yet improves the product’s quality.

Avoid pre-agile constructs

It can be hard to remove bias from pre-agile constructs. If you see yourself or your team using the following words, pause and reconsider your options: * specifications, * requirements, * the system shall…

In Summary

Avoid limiting yourself with pre-agile concepts. Recognize the flexibility of features in building software.

Here’s an academic paper demonstrating the negative impacts of framing potential system functionality as “requirements.”

For more information about the construction of preferences see

Considerate Pair Programming - Part 1

Why We Pair

Hi. I have come to love Pair Programming. I enjoy the collaboration, cross-training, and better solutions that emerge while I pair.

Continuous Pair programming with Overlapping Pair Rotations removes knowledge silos to increase teams’ resiliency to team disruption [reference] and builds collective code ownership [reference] as described in Sustainable Software Development.

Pair programming is a complex practice requiring skill to master. Although Pair Programming has been around for 20 years and is well researched, some teams simply drop engineers onto a team expecting them to figure Pair Programming out.

As a practitioner, I am still discovering ways that I can improve the pair programming dynamic.

This article describes 1) several techniques that can improve your pair programming experience, 2) strategies on what to do when things get frustrating or go wrong, and 3) concludes with success stories of converting difficult pair-programming relationships into successful pair-programming relationships.

Like any relationship, such as friendships, family dynamics, dating, or marriage, when pairing works well, it is an amazing experience; when pairing falls apart, it can be frustrating and occasionally super hurtful. While unfortunate dynamics can happen while pairing, I have experienced the joy of finding each other in the rift.

Pairing exposes both our strengths and our weakness. How we handle our weaknesses may have a direct impact on the pairing relationship. One of us might not be comfortable exposing our weaknesses. If we are experiencing imposter syndrome, feeling that we are not qualified for the job we have, we might fear that our partner is going to find out that we are faking it.

I have been on a journey to be a better pair. While at Pivotal over 3.5 years, I have paired with ~39 pivots and ~ 20 client developers. I am grateful to each person who has helped me better understand myself and have helped me assemble and create these techniques. If you paired with me and I did not apply the technique, it may be because I learned it later.

Considerate Pair Programming - Part 2

Strategies for Success in Pair Programming

In my software development practice, I rely on several techniques for increasing the probability of success with a pairing relationship.

This article contains a toolbox of techniques. Feel free to pick a few to try out and then revisit the list in a few weeks.

Become invested in your pair’s success is the major take-away. When I am taking care of myself and looking out for my pair, an incredible friendship can form. Consider “what are my pairs strengths? And how do they map to my weaknesses?” and vice-versa. Have I always been invested in my pair’s success? No. My pairs probably have stories on how I could have improved in my pairing. Shifting from “what is in it for me” to “what is in it for us” enables new pairing dynamics.

Considerate Pair Programming - Part 3

When Pair Programming Goes Wrong / Weird

Since pairing is a relational practice relying on imperfect communication, misunderstandings and slights can emerge.

What could go wrong with pairing? Here are some situations that have bothered me.

  • You come across some code that is difficult to read. Your partner tells you not to refactor the code.

  • Your partner dominates the keyboard for most of the day.

  • Your partner does all the work without involving you.

  • Your partner tells you how horrible is the code that you helped work on the previous day.

  • You discuss a situation and agree to a plan, but then your partner starts doing his / her own thing anyway.

In this section, I list out several strategies for coping with a situation that is getting tense, de-escalating a situation that is tense, and how to re-engage with your partner after a tense situation.

Sustainable Software Development

This table compares Sustainable Software Development to Extreme Programming

Sustainable Software Development XP Primary Practices
Balanced Team Whole Team (Balanced Team)
Shared Schedule, Be Present Sit Together
Managing a Backlog Informative Workspace
Shared Schedule Energized Work (40-hr week)
(Remove Knowledge Silos) Continuous Pair Programming Pair Programming
(Remove Knowledge Silos) Overlapping Pair Rotations
(Remove Knowledge Silos) Knowledge Pollination
Managing a Backlog Stories
Story Showcase Meetings Weekly Cycle (Iteration Planning Meetings)
Quarterly Cycle (Planning Game, Small Releases)
not needed when there is no commitment to each week Slack
Ten-minute Build
Live on Master Continuous Integration
(Caretaking the Code) TDD / BDD Test-First Programming
(Caretaking the Code) Continuous Refactoring Incremental Design (Simple Design Refactoring)
Retro N/A
2.0 Corollary Practices
User Research, User Interviews, User Validation Real Customer Involvement (On-site customer)
This is a specific tactic for replacing legacy systems Incremental Deployment
???? Team Continuity
Shrinking Teams
???? We rarely do this, it depends on situation. Root-cause analysis
Team Code Ownership Shared Code (Collective ownership)
Caring about Code Quality Code and Tests
Short-lived branches Single Code Base (branches live a few hours at most)
Frequent Releases Each team releases when features are done or at a given cadence Daily Deployment
Flexible Scope Contracts Negotiated Scope Contract
Avoid Technical Debt ??

Software Engineering Grounded Theory Research

If you are using Grounded Theory to conduct research in software engineering, I would love to hear from you. Please contact me at [professor at]

If you are starting out on grounded theory research, I would suggest this plan of action:

  1. Determine with variant of Grounded Theory that you want to use. Options include:
    • Classic / Glasserian grounded theory
    • Straussian grounded theory
    • Constuctivist grounded theory
  2. Read Stol’s comparison of the three major variants and recommendations on how to write grounded theory research.
  3. Read my lessons learned paper
  4. Read a few exemplars (e.g. Software Development Waste, Becoming Agile)
  5. If you select Constructivist grounded theory, then read Charmaz’s Constructing Grounded Theory
  6. If you select Glasserian grounded theory, then read Hoda’s Grounded Theory for Geeks and read Glaser’s books in order.

This month I finished my Ph.D. I have used grounded theory for the last three years. I have found the method extremely rewarding. I loved interviewing, participant observation, and analyzing the data. There will be moments of confusion with the data. Embrace the confusion, on the other side tends to rewarding research results.

We Know the Way - Phonetic Lyrics - Moana

We Know the Way – Phonetic Lyrics – Moana

Thank you Opetaia Foa’i for this fantastic song. It is my favorite from the Moana sound track.

I wanted to learn this song, yet the official lyrics are in Samoan, Tokelauan, and English (I think). Since I only speak English, I created these phonetic lyrics.

I slowed the music to 70% normal speed and listened over and over again. Note, we might not have all the phonemes in English.

Ta-toe Ta-na-to-pho-low


Le’-tua-tsome knee-te-lay


Oo-ah-pah el-lay-lu-ah toa-le-eh


Oh-loh oh-loh tah-kah

Away Away


Te mah new lay lay A ta key A

Away Away


Nah echo hockey lee-ah

Kah-ang nah-A

One of my hobbies is improv, and I play a game where we get our partner to guess multi-syllabic words by acting out each phoneme.

Remote Pair Programming

Developer pair programming

While at Pivotal, I have iterated on remote pair programming while working on two distributed teams. This shares what I have learned about remote pairing.

Best Practices

  1. Periodically check in with your pair about the audio, video, and screen sharing quality. Fix issues promptly. If you are experiencing issues, bring them up. Quickly iterating is the key to improving the remote pairing experience.

  2. Setup a video feed (zoom,, hangout, slack) that is always on and instant messaging (slack) in the secondary window. Much of communication is nonverbal. Seeing my partner excited or frustrated is super helpful.

  3. Leave the video feed running during breaks. This allows each person to see what is happening at the other end. If my pair is in an office, I might see that my pair is talking to another member of the team.

  4. In the office, leave the microphone open. This allows a remote person to feel connected to the office vibe when their pair is away from the desk. Osmatic communication can still happen.

  5. When a team is distributed between two offices but pairing locally, setup a remote video feed. This allows either office to get the attention of the other office by waving frantically. (Often pairs do not check slack frequently while pairing.)

  6. Use screenhero for screen sharing and zoom for video and audio. The audio in screenhero does not work as well as zoom or

  7. Have all pairs join the same channel. Mute everyone but your pair. Whenever you need a team huddle, just enable everyone’s channel. This reduces the friction for team huddles.

Here the team is in one channel with multiple conversations. Note that the team has an extra camera setup to see what is happening in the aisle: Brady Bunch View

  1. Ask for feedback about the development environment. While Pivotal uses workstation-setup for consistent development environments, the screen resolution difference between a laptop and an iMac makes that combination super tricky. I prefer iMac to iMac.

  2. If you are working across timezones, have empathy and be mindful of break times and lunch time.


  1. Use a two display system. One screen is shared. The other is for supporting remote pairing.

  2. In the office, use an audio splitter. Have two headsets on the splitter. When another co-workes interrupts you, ask them to join the conversation. Having a second headset makes this easy. At the minimum, use a splitter to reduce friction. I use Scotch 35 Electrical Tape on black Belkin Speaker and Headphone Splitter

If you are using 4-pole headsets, I recommend this 4-pole Headset Splitter:

  1. In the office, use an expensive headset with a boom microphone.

In the office setting, avoid using earbud headsets as they tend to let in too much office noise. If you prefer these, check in with your pair about audio quality.

I updated this page on 10/3/2017 with the reasons behind the recommendations.

Team Code Ownership

Team Code Ownership is “the ability for any developer on a team to change any of the team’s code.”

I’m presenting a paper on Team Code Ownership at EASE 2016 next week.

Read the paper on-line: Or download the pdf:

Summary of Paper

  • My observations clearly indicate that team code ownership is a feeling that can be engendered, not a policy that the team adopts

  • Pivotal developers more acutely feel team code ownership when i) they understand the system context; ii) they have contributed to the code in question; iii) they perceive code quality as high; iv) they believe the product will satisfy user needs; and v) they perceive team cohesion as high.

  • The paper shows that diverse events and trends that can undermine sense of ownership

  • The paper replaces Beck’s definition of Collective Code Ownership (“anyone can change any piece of code in the system at any time”) by introducing the new term Team Code Ownership (“the ability for any developer on a team to change any of the team’s code”)