I take it as a fundamental tenet of source control systems that I can put a file in now and get it out later, unchanged. Git breaks this rule: Git can convert line endings, which which regularly causes confusion and file corruption. Let’s stop that from happening.

If a critcial security vulnerability is found in a library we depend on, how quickly can we find out, apply the fix, verify, and ship to production?

Suppose we have some Python that depends on some 3rd-party libraries. How do ensure that those 3rd-party dependencies are stable over time, so we can get consistent results, in accordance with good engineering practice?

Programs are just data in memory

Code is just data. Running programs are just data in memory. Debuggers just inspect that data. What if we take a snapshot?

(Part 5 of a series on Windows debugging.)

Git doesn’t plug in easily with Source Server. How can we make it work?

(Part 4 of a series on Windows debugging.)

When you build your source code locally on your development machine and then run it under the debugger, the debugger finds the debugging information automatically. What about when you didn’t build the program yourself?

(Part 3 of a series on Windows debugging.)

When you build your source code locally on your development machine and then run it under the debugger, the debugger finds the debugging information automatically. What about when you didn’t build it yourself?

(Part 2 of a series on Windows debugging.)

Debug Info is the information about a running program that the debugger uses to understand that program. Let’s delve…

(Part 1 of a series on Windows debugging.)

Mocks are evil. Except for the Three L’s and TDA.

“Toil” is the work that takes time and energy human capacity but could be largely automated. “Technical Debt” is generally hard to measure, but Toil is measurable. It includes activities such as validating a code change, rotating credentials, and updating 3rd-party dependencies. The Toil Scorecard gives teams a way to measure these costs and make toil visible to the organization.

When we try to apply unit testing, a question that often comes up is “how can we test this difficult-to-test code?”. That question has an important built-in assumption, that the code as currently written should not change for the sake of testing, and shall be tested as-is. That’s unfortunate, since a big potential benefit of unit testing is that it helps you detect and repair harmful coupling. Let’s look specifically at some options for decoupling for testability.

Arlo’s Commit Notation (ACN) is a tool which can be wielded to solve certain problems: I use it to:

• speed up code review
• remind myself to take smaller, safe steps
• ship faster and more safely
• quickly scan commits for risk
• make rollback easier

If you are new to ACN it can be really hard to clearly see those problems and how ACN addresses them. I will try to describe it all in great detail in article format.

You have just completed Test-Driven Development Training with an excellent instructor. The class was great and you feel like you really “get” TDD and how awesome it is. You are ready to put it to work. You are ready to preceed every behavior change with a test, and to refactor mercilessly under a green bar. You try to apply your new TDD skills to real work and you run in to trouble. Why is that?

The software industry seems to like Fibonacci for estimates. I hate estimates so whenever we talk about them, I’m grumpy.

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:

Here are three very specific uses of Extract Method on a function that takes an unwieldy object as an input, to help make code cleaner and easier to test. I learned these from Arlo Belshee.

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.