The Password-Strength Checker Design Kata – Part 1

In two of my three technical courses (Essential Agile Engineering Skills and Essential Test-Driven Development), the first major topic I cover is refactoring, its role on an Agile software development team, and its role in software design.

Sometimes, but not always, the participants have the time and inclination to come back to the topic of software design.

Read More

Technical Debt, & the “Core Four” Practices to Avoid It

Readers! Subscribers! “Followers”! I hope you are all healthy and safe.

What is “Technical Debt”?

People are still debating over the one true meaning of the term “technical debt.” It was coined by Ward Cunningham around 2009, and the short definition is this:

Technical Debt is the deferment of good software design for the sake

Read More

A History of Test-Driven Development (TDD), as Told in Quotes

Nope, I haven’t forgotten that my next newsletter was going to be in response to a comment on the last newsletter. But I’ve discovered the need for some diagrams, or code, or something other than prose, to explain myself succinctly. So, it’s taking longer than

Read More

Can a Unit of Behavior Span Objects?

A client recently asked me if a unit test could test multiple objects. On the surface, you might suppose my immediate answer would be “No way!” But his question, and my answer were both a bit more nuanced than

Read More

A Dozen Reasons Why Test-First is Better than Test-Later, Pt. 3

The third and final part in the Developer Essentials mini-series of posts about test driven development (TDD). Click here, if you missed Part 1 or Part

Read More

A Dozen Reasons Why Test-First Is Better Than Test-Later (Pt. 2)

From the Developer Essentials Newsletter: The intersection of Agile methods and technical software development.

If you missed Part 1, review it

Read More

A Dozen Reasons Why Test-First Is Better Than Test-Later (Pt. 1)

An editor of Dr. Dobbs magazine once wrote to me—replying to my response to an article—“All the benefits [of Test-Driven Development] could be attained equally by writing tests after the code, rather than before.”[1]

Tests exercise software to be sure it’s doing what was intended. So, whether you use Test-Driven Development (TDD) or write unit-tests

Read More

Object Oriented Programming in a Nutshell

Next year I’ll likely be teaching Essential Test-Driven Development to a team that includes about 50% COBOL programmers. I told the client I’d look for a good object-oriented (OO) primer for those developers to read in advance. As you can imagine, it’s tough to “unit-test” software that doesn’t have clear “unit” boundaries. COBOL relies on

Read More