Change

We Haven’t Seen It All

Change, Coaching / / 2 minutes of reading

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

We Haven’t Seen It All See Full Post

Change the Problem

Change, Coaching / / 5 minutes of reading

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

Change the Problem See Full Post

About Interruptions

Coaching, Change / / 3 minutes of reading

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

About Interruptions See Full Post

HTTP Clients #3: The Cost and Benefit of Fat

Change, Coaching / / 6 minutes of reading
This entry is part [part not set] of 3 in the series HTTP Clients

So. We’ve talked now about cost & benefit for thin-client, i.e. browser solutions. What are the cost & benefit of fat-client, i.e. app solutions? There is one primary cost for a fat client, as opposed to a thin, and it’s obvious: It doesn’t write-once-run-anywhere. Now a couple of things. We’ve already pointed out that a thin client doesn’t do that, either. But — play fair — thin clients usually run at least "okay" in more places than fat ones do.

HTTP Clients #3: The Cost and Benefit of Fat See Full Post

HTTP Clients #2: The Cost of Thin

Coaching, Change / / 6 minutes of reading
This entry is part [part not set] of 3 in the series HTTP Clients

Yesterday, we started with thin (i.e. browser) clients versus fat (i.e. app) clients. We considered the alleged benefits of thin, which I believe we routinely overestimate. Today I want to talk about the costs, which I believe we routinely underestimate. I mentioned the other day how much I prefer a fat-client approach to today’s standard and largely unquestioned reliance on browser-based solutions. I want to step into it, even knowing I’m gonna get yelled at. Please do check the admissions

HTTP Clients #2: The Cost of Thin See Full Post

HTTP Clients #1: The Benefit of Thin?

Change, Coaching / / 4 minutes of reading
This entry is part [part not set] of 3 in the series HTTP Clients

I mentioned the other day how much I prefer a fat-client approach to today’s standard and largely unquestioned reliance on browser-based solutions. I want to step into it, even knowing I’m gonna get yelled at. Freely made admissions to start: 1) I admit there are situations where a browser is best. 2) I admit that some modern internet-stack environments are better than others. 3) I admit that most of what I’m critiquing is today’s typical practice, not necessarily "what is

HTTP Clients #1: The Benefit of Thin? See Full Post

From Procedural to Human

Pro-Tip, Change, Coaching / / 4 minutes of reading

Yesterday, we talked about Alice’s City On The Hill and her approach to getting there. I offered, instead of the Alice approach, an approach that was Human, Taken, Local, and Iterative. Today, let’s consider this business of Procedural -> Human. Every system for making software is a mixed system, with three kinds of thing in it: the human kind, the artifact kind, and the procedural kind. Humans are, you know, persons. Artifacts are things like the code, the tools, the

From Procedural to Human See Full Post

Alice’s Approach To Change

Pro-Tip, Change, Coaching / / 5 minutes of reading

Change Pro-Tip: It’s common, but mistaken, to believe that some change I want to make will be procedural, given, sweeping, and final. Let’s imagine someone, we’ll call her Alice. Alice is a mid-level manager, a department head let’s say, neither quite at the top nor quite at the bottom. She’s got some power, but not all the power, and she has a very strong desire to change how her organization works. You see, Alice has a vision — inspired perhaps

Alice’s Approach To Change See Full Post

What We Can’t Change

Change, Coaching, Pro-Tip / / 6 minutes of reading

Change Pro-Tip: We can’t (purposefully) change what we don’t sense, what we don’t talk about, or what we assume can’t be changed. I remind myself of this one a lot, because it’s easy to forget in the middle of the circus that passes for professional software development. Changing things means going from A to B in, idunno, operational space. For me to do that well, I need awareness of A. I have to be able to sense what I or

What We Can’t Change See Full Post

Change Pro-Tip: Lining Up The Betters

Change, Coaching, Pro-Tip / / 4 minutes of reading

Changing Pro-Tip: When I remember to line up the"betters", so my "better" is their "better" is his or her "better", my changes go a lot better. A refresher, my definition of coaching is "Creating or exploiting openings through which individuals, including sometimes myself, can step closer to who they wish they were." This is all about "better". When I am being paid to make changes in organizations, there are always a bunch of these "betters" floating around. There’s almost always

Change Pro-Tip: Lining Up The Betters See Full Post

Scroll to Top