Posts
How Do You Run a Postmortem?
Our process has failed us! The payment feature went offline, our team doesn’t have shippable code, and a user story has been in progress for two weeks. In order to deliver software at a consistent pace, it is essential that agile teams iterate on how they work. Below I describe the steps to facilitate a retrospective to address these problems.
So that this post is useful as a reference, I have made each facilitation step a header followed by a recommended time box.
read more
Posts
Which Type of Tests Should You Write?
When test-driving a system, it can be tricky to know which type of test to use and when. Rather than talk about the testing pyramid, I want to focus on the questions we want answers to.
Below I have organized feature tests, integration tests and unit tests by the questions that they answer.
Is It Wired Together? Whenever I start working on a new feature for a system, I begin by writing a failing feature test.
read more
Posts
Testing Patterns in Ruby: Contract Testing
Maintain shared behavior of multiple implementations by making them pass the same tests.
Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test.
Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.
read more
Posts
Patterns of Sharing Work Between Teams
While I was researching different ways for teams to increase their throughput, I stumbled upon a distinction that is often not made. Framework is often used to refer to both the framework pattern and subsystem pattern. Here is a short description of those two patterns and their tradeoffs.
Frameworks Frameworks are skeletal structures of programs that must be fleshed out to build a complete application — Rebecca Wirfs-Brock
Examples Spring and Rails are examples of frameworks.
read more
Posts
Writing Maybe in Ruby: Lessons Learned
I built a small framework, which retaught me why it is important to understand a user’s problem, ship early and iterate. Yes, even for frameworks.
It kicked off with a tweet, which expressed disdain for Ruby’s nil. The author yearned for a maybe implementation. Having just finished the Bowling Kata in Elm, a language which has a built-in Maybe type, I decided I could create a quick implementation. I didn’t anticipate how long quick was…
read more
Posts
When Should You Refactor?
I find that there are two moments that best suit using refactoring; practicing TDD and adding new features.
As part of the TDD flow, we restructure the code we wrote in the last ten minutes, after the red and green stages. We iterate until we find a design that is the best we can think of at the moment, for the features we have now. The best designs follow the Four Simple Rules Of Design.
read more
Posts
How to Stop Past Coworkers From Calling You
Are you currently the only one on your engineering team who can read and understand your code? If you left for a new job, how often would your teammates need to call you in order to maintain the code you left them? Let’s talk about how to not get calls after you leave a job.
Visual Hierarchies Visual hierarchies are a powerful tool. As readers they allow us to scan, giving us a sense of the main flow.
read more
Posts
Co-Signing for Technical Debt
Product and engineering need to see each other as co-signers on technical debt. The idea isn’t to say “no” to all technical debt, as you will definitely have to take some on. Rather, we need to have open and honest discussions about the state of the code and why certain design elements need to be fixed now and which ones can be deferred. Collectively balancing the need to deliver in the short vs long term.
read more
Posts
Why You Should Do One Story Until It's Done
Writing software is at its core a production system. The goal is to produce a product with just the right quality, at just the right time, so that customers find it valuable. With that in mind, let’s look at the types of things that can stop us from producing on time or at the right quality. There are 7 types of waste in a production system. They are:
Defects — product is low quality Over processing — product has excess quality Waiting — people are blocked Transportation — moving product in a way that doesn’t add value Inventory — product is stuck between phases Motion — moving people that doesn’t add value to the product Excess production — producing quantity than is valuable to customers Blocked Stories Are Inventory I want to focus in on one of these types of waste, inventory.
read more
Posts
Learn Programing by Intention: A Long Forgotten Programming Technique
I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.
read more