Stack

A stack is a linear data structure where the latest elements inserted are the first ones removed. This is also called Last In First Out (LIFO) insertion. You can think of it like a stack of dishes in a cabinet. You put clean dishes on top of the stack, then later when you need to use a dish you remove the top one (which was the most recently added.)

Pop the stack

To “pop” a stack means to fetch the “top” element by removing it. The stack is one item shorter. You’ve got an empty stack when you cannot pop any more.

Pop the why stack

To “pop the why stack” means asking “why?” repeatedly like a curious toddler. The “stack” here is a layering of reasons, excuses, or misdirections. At the very top of the stack is a software request, often a ticket. At the bottom of the stack is truth, satisfaction, or sometimes disappointment.

So when do you pop the why stack? Let’s say you’re a software engineer working on a custom EMR software for therapists and you receive a ticket “Add a button on the session screen that copies all the notes from another patient”, and your Spidey-sense start tingling. You know some things about the software and think “that’s weird, why would they want to copy from another patient?”

So you gather whoever wrote the ticket (product manager/owner) and any relevant stakeholders into a meeting. You show them this ticket and the first question you ask is… you guessed it: “Why?”

You: Why do we need to “add a button on the session screen that copies all the notes from the another patient?”

PM: Because the therapists say they’re tired of manually copy-pasting the notes between patients.

You: Why are the therapists copy-pasting the notes between patients?

PM: Hmm, not sure. Let me ask the therapist I talked to… Oh they say it’s because they saw another patient at the same time.

You: Why did the therapist see the another patient at the same time?

PM: Let me ask… Ok, the therapist says they held a group session with four patients.

Aha! You’ve discovered something. Since you know a little bit about the software, you realize it wasn’t initially designed to handle group sessions, and the therapists have found a manual workaround. Since you’re a smart engineer, and you know what’s achievable in the software, you can come up with a less laborious solution.

You: OK, so it seems the root issue is that therapists are recording group sessions as individual sessions.

PM: Yes, that makes sense.

You: Why don’t we instead add a new screen to record group sessions? All involved patients get the same notes in their file. That way the therapist only visits one screen instead of four.

PM: That’s a great idea, why didn’t I think of that…

You’ve popped all the why’s and you’ve found satisfaction.

Prescriptive Tickets

Sometimes you will find yourself working on a team that repeatedly falls into this pattern. You’ll come across tickets that are a prescription of a solution, rather than a description of a need. Like the example above, the ticket was a prescription of a solution: “Add a button on the session screen that copies all the notes from another patient”. Those might even be the exact words of the therapist using the software! Prescribing a solution will always bake assumptions into a ticket, and exclude the perspective of an engineer. Writing prescriptive tickets isn’t always intentional, but it can happen a lot on software teams that work closely with their end users.

Instead, your team should strive to make tickets that are descriptive instead of perspective. One approach I’ve seen work is to use user stories where possible. If the example above was written as a user story, it might read “As a therapist I want to record group sessions so that involved patients have the same notes in their file”. This requires more homework up front from the ticket writer (product owner/manager) to discover the true user story, but it can prevent a why stack moment in the first place.

Preventing why stack moments

“Why stacks” are inefficient for several reasons. Firstly, if nobody knows to pop the why stack before a suspect ticket is implemented, tested and released, the result is inferior or incorrect features in the production application. It’s much costlier to refactor a feature after it has hit production.

Secondly, popping a why stack forces a ticket to go backwards in a software development workflow. It must reenter requirements gathering when it should have been ready to work on, slowing your velocity.

Preventing why stack moments can be a matter of training others or sometimes “managing up”. If you’re an software engineer, you might need to challenge your Product Manager and/or Owner to write more “Descriptive Tickets” if they’re used to writing prescriptive ones. If you’re a Product Manager, you might need to lean on your engineers to assist with ticket writing. Work together to write Descriptive Tickets, then work together on “Proposed Solutions” in the contents of the ticket. This forces a discussion with the engineers of how to best solve the problem. Engineers are natural born problem solvers, and know the software deeply and what it’s capable of. Once “Descriptive Tickets” get ingrained in the culture, hopefully you will see a decrease in “why stack” moments.

Conclusion

It’s impossible to eliminate “why stack” moments completely, so it’s an crucial for a software engineer to know how to pop the why stack. Over time, you will gain an instinctual sense of when it’s necessary to pop the why stack.