July 2019

Refactoring Pro-Tip: When I choose a side-by-side approach, I start by finding (or making) the "pivot mount". the place where the final switchover can take place safely. (So, I re-read that last muse, the one driving this, and I blanched. I didn’t say that very well. The price we pay for extempore musing, I spoze. Still, it’s a worthy topic, so let’s see if I can keep my promise to talk about how, even tho I change terminology from the

I was on the road half to two-thirds time for for about 25 years, nearly always visiting or working with software teams. I’ve worked with teams as small as 2 and as large as 500. I’ve worked in the US, much of Europe, and even a bit of China. The orgs involved might be centered around software, product or service companies, or they might be IT departments, embedded in far larger organizations. The kind of software? Oh, every kind. Embedded

I’ll tell ya a story. Once upon a time there was a team that had it pretty good. They were internal-facing in a VBCA, supporting a variety of analysts of different types, with about 3 dozen small projects clustered around a large but mostly stable analysis model. The work was mostly about fronting the analysis model in several different ways to several different other teams, each of whom had different (fairly cool and interesting) needs. So they rolled C#, and

I saw the five-minute meeting with developer thing again. Not offering it here cuz I don’t much want to give it the publicity. The gist: when you interrupt a developer the time-loss is far greater than the duration of the interruption. There are three cases being made. First, that developers are a special class of people in this. Second, that the value gained by the interruption weighs less than that lost by it. Third, that cost-of-interruption for developers is an