Thread by @GeePawHill

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.

https://twitter.com/GeePawHill/status/1141452176583270402

Please do check the admissions at the beginning of that thread. They're still in effect here. I want to stress, especially, that I'm talking about the standard practice in the trade, not about what might be possible but isn't normally implemented.

Nearly all of the costs I'll discuss could be slid under a single heading: the consequences of complexity. But I want to call them out in a slightly different way. I want to talk about them in terms of the Made, the Making, and the Makers.

Thin-client benefits, whether they're real or not, are inevitably about the *made*. That is, the "finished" product we're hoping will increase our bottom line in some way.

Thin-client costs, on the other hand, are incurred very heavily in the *making*, the manner in which we work on our way to getting to the made.

And of course, things that affect the making inevitably affect the makers, too. When the making is grim -- a word I am choosing carefully -- the makers are very likely to suffer from classic attributes of depression: listlessness, avoidance, unhappiness, boredom.

A key aspect the agility I believe in -- there's no brand name or school -- is that we seek to embrace change by maintaining a three-way *balance* in our attention, between the Made, the Making, and the Makers.

Browser-by-default becomes the default based first on illusions about the benefit of the made, and second on the costs placed on the other two legs of the tripod. Let's take a look at some of these costs.

A typical browser environment involves at least two parts, a front and a back. The front normally involves *three* different formal languages: HTML, CSS, and JS.

But it normally also involves at least one additional "psuedo-language", the particular JS framework one is based in. Sometimes, of course, that's really 3 or 4 different psuedo-languages.

I call these psuedo-languages because each one effectively introduces both significantly different syntax & semantics.

The back end normally involves at least two languages, your base language itself, like java or ruby or, idunno, COBOL, and your data language, normally a dialect of SQL.

Most backends incorporate two psuedo-languages, as well: one to manage the transport protocol, and one to manage the SQL interactions. They may include others.

Are you counting? That's 6 formal languages. *Six*. That's the low end. Add a cool new framework for drawing calendars. Add a template engine, except you have two layered template engines, one driving the one below it driving the html. Add hibernate in back, to go with spring.

Now, geeks are typically fluent in several geek languages and familiar with several others, just like anyone but Americans are typically fluent in several human languages and familiar with others.

It isn't just language count. It's language usage. To do even trivial tasks in a browser world, you have to use *most* of those languages *most* of the time. You flip language contexts a dozen times a day.

There's a factoid one sees periodically citing research about context-switching. The common version of it: every time you context-switch you lose 10 IQ points.

Think about that cost for a minute.

Now a little mix-in, too. Because you see, most of the tools we use in that multi-language environment cover two or maybe three of those languages. So we're not just switching languages in one tool, we're bouncing tool to tool.

So, multiplicity of language context, then multiplicity of tool context. Both are pricey as hell. And when the making gets hard, guess what: the made comes out more slowly.

But we're not done with cost yet. There's also multiplicity of program. You see, a thin client always has to bounce against a server. Those are required to be two different programs in a browser environment. *Required*.

And both of those programs have to be bounced -- stopped, started, refreshed -- all the time, because we're changing both of them. Browsers are *fast* to reset (if you've figured out how to turn off their caching). Servers are *slow* to reset. And you can't do both from one tool.

Now what do you do when you have a step that takes a long tijme? IF you're like nearly everyone else on the planet, you do it less often. This means you store up a bunch of changes, type type type think think think, and *then* you go through the bounce.

The result: not only do you get slower that way, but you also get effectively dumber. Okay, you make the same amount of mistakes, but it takes longer for you to discover each one, so it allows you to reason based on inaccurate premises for much longer.

And if you act before midnight tonight, we'll throw in yet *another* cost: services are routinely built to be deployed to environments that aren't the developer's box. (Note: it wouldn't have to be done that way, it just normally is.)

But orgs see those external server farms as *cost* centers. They become scarce resources. They are policed by process groups. They are restricted in access. They are *shared*. And ditto -- but a different process committee -- for the databases.

This (I repeat, entirely by choice, it would never *have* to be that way, it just *is* that way in most IT shops) cost is like a great beautiful cost *multiplier*. It takes whatever expense you started with and makes it even bigger.

And one more, another optional cost: poor old designs of services where the backend service depends on other backend services that are just as badly built as the one you're working on. Wouldn't have to be that way, but is that way. At this point, the cost heads to exponential.

There are other costs, smaller ones. But I think you get a picture.

Now. Let us be as clear as possible, lest we just fall into idle ranting.

1) The point isn't that those costs are never outweighed by those benefits. The point is that they need to be looked at every time. A default "put it in a browser" approach is not a good default.

2) A great many of these costs are not actually required by the internet stack. Rather, they are *chosen* by orgs.

3) The fat-thin choice is an excellent example of a place where we need to attend very carefully to all three factors in our agility. The Made, yes, for sure, and also the Making, and always the Makers.

I'm going to pause for about a half-hour, then I'll be back for my next trick:

What are the features of a fat client approach that make it different? How *much* different, cost and benefit both?

Stay tuned! :)