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.
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
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
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
From the Developer Essentials Newsletter: The intersection of Agile methods and technical software development.
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.”
Tests exercise software to be sure it’s doing what was intended. So, whether you use Test-Driven Development (TDD) or write unit-tests
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