Industrial Logic Blog

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 […]

When testing tricky collaborators, we may create fake or mock objects to make life easier. In effect, we draw a line: on one side, real objects participate; on the other, it’s fakes and/or mocks. Consequences of the Line A common strategy for testing with mocks: Test standalone objects directly Use fakes and mocks to test […]

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?

By Alexandre Freire Kawakami and Felipe Castro Agile adoption in most companies focuses on software delivery. Very few achieve business agility.

Have you ever felt that someone’s behavior was hostile or aggressive towards you, formed a negative opinion about them and then taken protective action(s) against them? If so, you’ve likely participated in a Cycle of Mistrust. In their must-read book, Driving Fear Out of the Workplace: Creating the High-Trust, High-Performance Organization, Kathleen Ryan and Daniel […]

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?

What’s the best way to deliver and grow systems? There are several possible approaches. One approach is pure waterfall: “plan the work and work the plan”, phase by phase, with a big bang delivery at the end. Measure progress by “(estimated) % complete”. A second approach is used by many Scrum teams: develop a Release […]

Do you find yourself creating code for similar methods or classes, and feel like it shouldn’t be so hard? You may be able to Harmonize Code and Introduce Identity Elements to make methods and classes melt away.

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?

When we wish statements were in a different order, the Swap Statement refactoring sometimes lets us swap them.