Industrial Logic Blog

Test-Driven Development (TDD) is frequently misunderstood in ways that cause needless struggle, delay, and upset. Misunderstanding and misrepresentation have been painful enough that developers have cried out in frustration, sometimes declaring the whole practice harmful, pointless, or even “dead.”

Mob programming is great stuff! We have found it to be the best way (so far) to teach technical skills to teams of programmers, and the best way for them to continue developing and teaching their skills well beyond our workshops. Here are a set of tips that help us to make mobbing more successful […]

Several decades ago, the software industry was obsessed with counting lines of code per programmer per month. That metric practice famously drove teams to create bloated, defect-ridden software products. After only a few years, the practice was abandoned as detrimental. Sadly, the biases and flaws behind that practice are with us still, influencing our practices […]

It’s great to have reliable tests in your pipeline to avoid escaped defects and to shorten the feedback loop for your programmers. Sometimes the build-and-test processes becomes a productivity-limiting problem. What do you do when your test suite takes too long to run?

When we are refactoring, and especially when we are teaching refactoring, our partners are surprised to see us extracting methods which are only (currently) called once. There is often an assumption that the only reason for extracting a method is so that you can call it from multiple places in the code base.</p> While this […]

Typical training workshops are informative and can be a lot of fun. Teams get away from their normal work for a week or so, try out new technologies and techniques on prefab examples, give the instructor a quick rating, and then go home to their normal jobs. Is this the time for traditional classroom training?

The Agile world is awash in metrics and measures, but most provide little benefit to teams. What if we could change our set of measurements to support safer software development, continuous improvement, happiness of our project community, and careful craftsmanship? In short, what are some Modern Agile metrics?

Large changes are hard. Hard enough that they seldom happen, outside the context of a crisis. What if changing wasn’t a traumatic event but a lightweight, continuous process?

Let’s say that I ask you to calculate all the happy prime numbers between Planck’s constant and the speed of light expressed in meters per minute. Did you immediately start reciting numbers to me? Odds are that you did not.

Here is a story board to consider. Is it healthy? Is it being well-operated? New scrum practitioners may say that it looks great if that’s the first day of the sprint, but indicates serious problems if it looks like this on the last day or two.