We’ve seen how refactoring becomes the primary design activity on an Agile team. Diligent, confident refactoring is possible to the degree that the code is tested through an automated test suite. If the tests don’t cover a portion of the code, a defect may be introduced when that code is altered. If the tests are
Last month we talked about good software design and introduced the notion of code smells. Code smells are names given to those instinctual thoughts you have whenever you look at a chunk of less-than-elegant code. Some are subtle, and some really stink.
I’ve learned not to assume a team has experienced a variety of software design skills. Some are writing elegant functional-paradigm code in archaic, challenging languages. Others are writing strongly-coupled, heavily-commented, and procedural static methods in Java or C#.
I was recently asked about the difference between unit-testing and Test-Driven Development (TDD). Specifically, why—if the end results are the same—would I recommend TDD over writing unit tests after coding?
What are the Agile Engineering Skills, Scrum Developer Practices, or Software Craftsmanship practices?
These are three (of many) common names for a set of practices assembled in the mid-1990s to support and improve Agile
Let’s cut to the chase: No one likes meetings. A status meeting every day is enough to drive you crazy.
Welcome to my new blog on the Agile for All site! Along with new posts, I’ll be interleaving updated, edited, and timely posts from my earlier independent blog. My posts will lean towards technical practices and skills, but always with an eye towards the business value and the humanistic dimensions of those technical topics. Here’s an