Thread by @GeePawHill

Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making.

It's Sunday, which is geek comfort food day for me. Remember, tho, to think and feel and work outside the monitor. Please help me in opposing the multiple ongoing efforts to suppress the votes of millions of American citizens.

Black Lives Matter.

A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app.

We tend to overlook it, but when we run our unit tests, for instance, we're actually running a making app. Whole great swathes of the code are exactly the same code we ship, just put together in a different way.

But there's no reason to have just one making app, and no reason to limit its capability to only running our microtests. We can do all sorts of cool things in a making app.

As long as its benefit to us -- improved productivity on the shipping app -- is less than its cost to us -- time spent working on something we don't ship -- we are winning.

Modern internet-stack apps, be they service-based or monoliths, already have UI's, of course. If you work backend, the odds are good that you spend more or less all day every day firing up browsers, banging in don't-care fields, waiting for internet latency, and so on.

The fact is, you're probably waiting on your code to get executed more frequently, for longer, and less cheerfully than any of your users ever do.

Furthermore, the users aren't waiting for startups, for connections to be made. And they don't know the screens that are in front of them. Those 7 mandatory fields they fill out are meaningful to them. Each intermediate page in the flow gives them info that's relevant.

But for you? It's all just a tedious slow process of run and wait, refresh and wait, click and wait, "asdf" and wait, and so on.

And, most importantly, your users are using an app that's built for *their* purpose. You're not a user, you're a developer, and you have a different purpose, and, unfortunately, you're using the app built for *their* purpose, not yours.

What would be cool would be if we could use an app for our development that supported our *developer* purpose.

Ya know, if we had a programmer, we could do that.

<ba-dump-bump-chhhhhhhhh>

Putting a *second* UI on your internet-stack app sounds incredibly grim. Imagine, even *more* endpoints, even *more* json, even *more* URL's. There are occasional situations where it might be worth it, but it's hard to imagine it helping much or often.

But wait a minute. We don't *need* the webbiness of our shipping app for developer purposes. Or, anyway, not for most of them. Our backend concerns are about business logic, flows, decisions.

In fact, not only do we not particularly need an http transport layer the way the shipping app does, but there are scads of other required aspects of the shipping app that we don't care about.

We don't need authorization. We don't need branding. We don't need one-concept-one-page. We don't need it to look awesome. We need it to connect not to the controllers in our code, but to the next layer down.

(In some tech stacks, of course, controllers are just plain old objects with methods you can call using plain old objects. That'll do, too.)

And it isn't just stuff we *don't* need. We can add stuff that we *do* need. Here's three examples of things we can do in a desktop app that are wildly useful to us when we're making.

1) We can log right on the screen. Right there. We can filter it interactively, too. And we can add our notes, custom data layouts, and everything else to that same log.

2) We can add buttons to do "play like" stuff. (American kids often use "play like" as the intro to a pretend game. "Play like I'm a robber and you're arresting me.") We can one-click "play like I've filled out the first four pages as a robber and you're notifying the feds.")

3) We can show the same info a user sees, or less or more. And we can do it compactly and cleanly, with noise suppressed and signal emphasized. It's not page after page of irrelevance, and it's not 4,000 characters of JSON, either.

Now, this isn't free lunch, of course. To pull it off, you need several ducks lined up just so. But the thing is, you *can* line them up just so. They're your ducks!

The code works for you. You don't work for the code.

Duck: Your backend environment has to be capable of having a UI. Fortunately, nearly all of them do. And your worst case is figuring out how to emit a clear-screen to a shell window and re-draw the whole thing in ASCII every time. Believe it or not, it's *still* valuable.

In Java/Kotlin, I use JavaFx/TornadoFx for this purpose. It's fast, it works, and I'm not doing brilliant UX design here, I'm slapping controls up on forms in tabs, I'm doing list boxes and trees. It's dead easy to put a javafx front-end right inside your spring boot app.

Duck: You have to be able embed the core of your shipping app in the UI making app. You don't want to be launching it separately and sending HTTP or RPC stuff. You just want to call it.

That means you will have to have completely isolated your business logic from your transports. Let me be blunt: I *told* you not to intertwine that stuff. If you haven't, you're good to go. If you have, well, gotta untangle that first.

Duck: You gotta deliver real value quick like a bunny. That is, even the crude v0.1 of your making app has to be seen by your team as "better than what we had". If it's not, no one will use it, and you'll get yelled at for not working on the shipping app.

Fortunately, most internet-stack backend development is so wildly inefficient that even the lowest hanging fruit in your making UI can double productivity. A lowly coherent custom presentation of message traffic, dead easy to make, can move hearts and minds pretty quickly.

Once you start down this path, believe me, the possibilities are really open-ended. Let's look at some variations on the theme.

I framed this discussion around backend internet-stack work, but in fact, a making UI is useful in all sorts of environments. You can use it for embedded work, where the "play-like" and "logging" functionality can pay off big-time.

If you read about the ScenarioBuilder idea from last week, you can make the SB a deep part of your making app. Imagine being able to one-click a scenario into place and then mess around with your app on a screen, right on your desktop.

Are you running multi-service? You can have one making app that is running *all* the services in one binary. You can run them synchronously or async, either way works.

You can even run some of the services remote and some of them embedded in the making UI. And you can simulate/simplify their datasets, too. I have done this many times, and it's a dream in a fast-changing multi-service environment.

For complex page-flows, this is an app in which it's easy to write tests to prove that your business logic, spread all over hell's half acre in the shipping environment, is doing what you think it is.

Implicit state is a huge complication in large multi-service environments. Using this kind of app to tease out the implications of a proposed data change is a million times faster than trying to use the shipping app to prove it, or studying code until your eyes bleed.

So.

Give it a try. A lot of the ducks sound harder than they actually are. And its even easier, of course, if you're starting a new project. You might be surprised at how quickly the cost of a making app UI amortizes itself. The first time I did it I was *amazed*.

Your users like your shipping app because it has been custom fit to their purpose. But their purpose isn't yours. And you're a programmer. So write the making app, using many/most of the same parts, arranged differently, and focused on *your* purpose.

Thanks for reading along. If you like my content, do me two solids:

1) Subscribe. It's free, spam-free, full-text or audio, and it helps me.

geepawhill.org/subscribe (That page is down just this minute, but we're working on it, should be up again soon.)

2) Keep working for change, in the code, in the team, in the org, and in the world.

We can change this. We're the only thing that can change this.

Black Lives Matter.

Black *Voters* Matter.