Ideally tests would be fast, reliable, easy to own, easy to maintain, etc. Let’s make a list that we can use when creating, improving, or evaluating our tests.
Having done Game of Life at Code Retreat a number of times, there are a few often-silent early choices which have a big impact on how the session goes. Neither of the options in each pair are the “right” or “wrong” option. My purpose is to encourage you to recognize that these options exist, and to pick consciously.
#BugsZero means a lot of things. Here are a bunch of definitions:
As I’ve practiced refactoring over the years, I continue to find new ways to solve problems better with refactoring. This is why refactoring is such a big deal to me.
Some years ago, our organization used an open source project to run one part of our business. It was good but not a perfect fit. Since it’s open source, we modified it to add the features we needed.
5-year repost! I reference the original post a lot, so I thought it would be a good candidate for reposting here on the new blog. I’m revising the text, but the core message is the same.
I’ve noticed people argue for (or against) #NoEstimates in a bunch of different ways. They’ll often say “what #NoEstimates is really about is…”
When people use the term “DevOps”, what do they mean? Here are the definitions I have seen people use:
You have a problem. You: Ah! I know! I use a distributed system. Now you still have a problem, but you no longer know where.
I hear two main objections/concerns about refactoring: safety and cost.
I feel like this is already well-covered ground. We already know never to rewrite from scratch. The demise of Netscape has been discussed thoroughly. So I’m only going to be able to add a little.
A tale as old as XP…
When Safeguarding we want to reduce the size of a genus of bugs by 15% each time. So what makes a genus of bugs?
At Tableau we use the term “Safeguarding” to describe a particular way of reducing future defects by learning from past defects. Arlo described it in a parable. Here’s my current concrete understanding:
My current understanding of Disciplined Refactoring is that it combines:
Given arbitrarily-complex C++ code with incomplete test coverage (aka The Real World) how can you extract a function, without relying on complete understanding or complete test coverage to ensure correctness of the refactoring?
This week we ran a #mobprogramming session with 35 people. Here are some notes about how that went:
I use Ports-and-Adapters to abstract away my application’s interactions with external systems. I bend the dependency’s interface to the shape that I want for my domain. This makes it easier to think about my code and to unit test it.
This uses Jekyll Now to give me a no-administration, code-friendly blog. I love the combination of Markdown + Git.