June 2019

HTTP Clients #3: The Cost and Benefit of Fat

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

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?

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

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

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 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

Scroll to Top