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.

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.

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.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

28 Mar
My friend Steve, I was spozed to be the pro from dover, told me this thing, and for, idunno, 17 years or so(?), I've been holding on to it. He said it boils down to two things. Don't waste time. Accept the whole person.
NB: It doesn't mean "accept everyone". It means, if you accept my geek chops, or you accept my sex appeal, or you accept my brilliant theorizing, you gotta accept my (considerable) doofusness.
You can't take my good days and not accept my bad ones. And if you can't handle my awful, why are you prepared to cash in on my valuable?
Read 5 tweets
21 Mar
In a data-rich environment, we can use the Builder concept to make DSL's for our Making application. This often makes testing the hard business core of our code both faster and easier.
Folks, I love sharing my geekery with you. For me, it brings much comfort. I hope, tho, you'll join me in working for change that isn't just about code, but about the larger world.

Black Lives Matter.
We've spoken in the past about using our codebase to do more than one thing. We always use it to create our shipping app. But we can and do use it for an app that improves our *making* process. We call that the making app.
Read 33 tweets
19 Mar
Honestly, y'all should read WCW more seriously before you gimme the parody.

Not hating. Just saying.

This dude rang the bell a dozen times in his career.

Imagine that.
My favorite WCW, my top-five poem of forever, is this one.

So. Love you, do love you, for real. But your fridge plum thing is old and tired and disrespectful of a poet who shakes the world.
Read 5 tweets
19 Mar
Here my Stevie, rescuing me as he does surprisingly often. "Heaven Is 10 Zillion Light Years Away".

My heroes show up, randomly, just in time.
This was the song that helped me grasp the difference between anger and hate.
Read 5 tweets
19 Mar
Aight, double-play. Here's Melanie twice.

First, "Brand New Key".

At some point a person reaches an age. And at that age, it's not in years, it's in living. And at that some point, one understands what a lovely song this is.
Then, caught up by her charm and her voice, one encounters "Lay Down".

Read 5 tweets
7 Mar
Approaches in software development -- or anything else -- that don't take ordinray human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let's dig in on that.
More geek joy comfort food from me today, but please think & work outside the monitor by enabling and encouraging change in our wider world.

Black Lives Matter.
Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot.
Read 29 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!