So many choices, Part 2

Yesterday, I lamented that web development hadn’t come to any consensus on tooling. programming language, basic UI framework or anything else.

I was talking about front-end development, but it’s true on the back-end as well.

Here, I’m not so sure if we could ever get consensus. On the front-end everyone is running in a browser and ultimately has to provide HTML, CSS, and Javascript. I was hoping that would have driven the industry towards one obvious choice.

On the back-end, everyone has been using their tool of choice for decades, and using Javascript (via node) is a good choice now, but it’s not close to universal. And if you are only working on the backend there isn’t a requirement to know Javascript at all, so there are lots of teams that don’t care about matching languages.

For me, using one language on both the front-end and back-end is such a compelling benefit, that I’ve moved to node for anything new. In practice, I haven’t had much code sharing, but I am flipping back and forth so much while developing, that just having to have one language in my brain is reason enough.

And since I use GraphQL, again Apollo is an obvious choice.

Before this, I was using Django and Python for my backends, and I like working with an ORM for SQL data, so I decided on TypeORM. Here there seemed to be 1 or 2 other viable options as well. TypeORM can be DB engine agnostic (depending on what you use), so setting up an in-memory, sqlite version for unit testing is pretty easy.

With Apollo and TypeORM, TypeGraphQL is a nice addition. It lets me have a DSL that describes entities in one place that generates my DDL, queries and also encodes them for GQL/Apollo automatically. If you don’t do this, a lot of your GQL code isn’t going to be type-checked.

My backend is essentially just a DB with GQL in front of it right now, so there isn’t much else to decide. Since I use the same language as my front-end, I can use eslint, prettier, and jest here as well.

The one thing I miss from Django is the automatic admin console and user management. In the end, I do think my admin interface needs to be more custom, but it’s useful at the start until you get around to making a real one. I looked at AdminJS, but unfortunately I had already committed to some TypeORM choices that it couldn’t support. If I thought I’d be on AdminJS long-term, I might have backed out of those choices.

In any case, the choices on the back-end mostly depend on what language you choose. As an iOS developer, I never really had the option of using one language for the full stack—I usually want to make native apps and Swift isn’t ready for the server-side in my view. It’s nice to have this option, and would make me reconsider ReactNative if I need a mobile app for this project.

So many choices

Up until about March this year, I was primarily an iOS developer and had been for a while. But, this year I decided that the things I want to build would be best built on the web, and so I started to learn modern web development. I was struck by the lack of consensus about what that means.

My goal is to build a real web app, not just to learn. I already know HTML/CSS/JS going into this. If your goal is to get started or just to learn, I’d start with HTML/CSS/JS and maybe React or Vue and not worry too much about the rest yet.

Right now, I’d say, if you want to be an iOS developer, you download Xcode, write in Swift, use UIKit for the UI and standard components and libraries and you can build professional apps. There’s built-in support for most things that you need, and the Apple implementations are excellent. All of the apps I have worked on are not much more than this.

On the web, I’d say the one consensus choice is to use VSCode, but then it starts bifurcating quickly after that.

The default language of the web is Javascript, but you can use anything that transpiles to it. I have decided on Typescript, but I think Clojurescript is a reasonable choice. There are probably a few others.

At this point, you basically have nothing. The browser provides an HTML renderer, very basic components, and a limited library. You are going to need to add dependencies to do anything beyond the basics (you had to do this even to get Typescript).

The first choice I had to make was what UI framework to use. I chose React, but people I trust also use Vue. There are few others that seem reasonable, but React seemed a good fit for me. By the way, if you want to get started with React, I recommend Pure React, which is a book explains React in isolation.

It might be overkill, but I decided to use Redux to manage state. React has something built in now, but I like things that have been around a while.

I also needed a design system — something with ready-made components. I didn’t find anything that great, but chose Material-UI in the end as it seemed the best supported.

I wanted to like Microsoft’s Fluid, but I couldn’t get it to look right for me. I also could not get Ant to work at all (I’m a newb at this). Every big company seems to promote one of these — my old employer, Atlassian, has ADG, which looks ok. SalesForce has one too. But, they all seem to have a different idea about what a reasonable amount of markup is for default usage. Material-UI is usually a simple tag with a few attributes to get something on the screen — these other systems are way more complex. There is also a vibrant commercial market for components. I will probably revisit this after my MVP is done.

I decided on GraphQL as my API basis, and so I got another easy choice: Apollo. I also added GraphQL codegen because it can turn GQL into a Typescript API (with typechecking).

It doesn’t stop there. I have eslint, prettier, and jest as my code quality tools. I think those are default choices, but there were others. In iOS, code formatting and unit testing are built in.

And this is all just to get something minimal working. I have also had to add in some other components for specific features.

I have also checked in with people in my network that do this for a living, and I haven’t found two that have made the same choices. Except for VSCode — that does seem universal.

Tomorrow, I’ll talk about the backend, but there is no comparison with iOS, since you’d have to decide on this as well for a server backed app.

Socially acceptable cameras in AR

At some point, there’s going to be an AR device that looks exactly like glasses. I also hope that they don’t have cameras. If they have a camera, then they also need an indicator that it’s on. Walking around, for example, NYC with people wearing the glasses equivalent of 2000’s style iPod white earbuds is probably creepy. There’s no way around it if they also have lights and cameras.

But AR needs reality to augment, and a lot of reality is percieved visually. So, without a camera, these glasses will be a lot less useful. If we look at Apple’s AR features as a guide to how it feels about cameras, you can see that they are pro-camera. At WWDC 2021, they demoed a feature where you can orient yourself in a city by pointing your camera at the surrounding buildings. This would be very useful in a heads up display.

So, we will probably have the front-end of a camera to take in visual information. But, AR could still be very useful without ever producing a visual from the hardware.

One obvious (and currently available) representation is a depth map. Apple is testing out LIDAR on iPads and use a depth sensor on iPhones for face detection. The representation is a mesh, not an image, so it might be acceptable and is useful for a lot of AR.

Another thing they could do is pre-process the video feed into a given set of layers in a neural network. The first few layers in an image processor usually do some down-sampling and feature extraction. I’m not an expert, but if these things cannot be reversed back into the original image, they might be acceptable. In current feature detectors, you can retrieve some bits of images (see this), so there’s some work to do. But even if this is ok, it’s a big public education project to get it to be socially acceptable.

But Apple has shown some willingness to talk about its privacy protecting “provably cryptographically safe” technologies and open them up to third-parties for verification, so maybe they’d be willing to go this route to get a “camera” into their AR glasses.

Apple Fall 2021 Event Wishlist

I’ve done a bunch of WWDC wishlists (e.g. 2021, 2020, 2019), but I haven’t done one for the main hardware event, which is this Tuesday.

I’m sure that the iPhone, Apple Watch, and maybe even the iPad (or Macs) will get nice improvements, but I can’t think of anything more I’d want. I am on the iPhone upgrade program, so I’ll end up with a new phone regardless. And the trade-in value on watches usually makes updating a reasonable option.

So, the main thing I’d hope for is something in AR. I’ve written about how I think AR could make apps more like games, and I do think that there’s space for a workout AR device. I would love to extend Sprint-o-Mat to make it feel like you’re in a race against the pace-runner. It would also be a good addition to Fitness+, which could extend to outdoor activities.

It feels inevitable that there will be something in AR eventually from Apple. I think one social issue is what to do about cameras on AR devices, which I will address tomorrow.

A Tale of Two Restarts

I injured my hamstring right before I was set to run a marathon this past June. I went to a few physical therapy sessions to see if I could do anything to salvage my training, but ultimately I decided to not do the marathon and greatly reduced my running volume so that I could heal.

And then I just stopped altogether.

I was traveling and my hamstring wasn’t getting better, and I just wanted to not think about it for a few weeks.

At the same time, I also stopped writing and podcasting.

By the time I got back, my hamstring felt great. I had lost a bit of fitness, and July in Florida is no time to train or run marathons, but I did settle back into my normal summer training regimen. I had restarted immediately without really trying that hard.

I did not restart writing. What was the difference?

For one, I’ve been running for a very long time, and I have gotten a lot out of it. I generally believe my health depends on me doing it. And, in the past three years, I have been doing it very consistently. Every run I do now seems to pay off immediately in self-esteem, weight maintenance, and feelings of fitness.

Although I’ve been writing over the same period, I have only gotten very consistent six months ago. And, although I have had successes, the benefits of continuing are not as clear. I have data that shows I am slimmer, faster, and more efficient. I don’t have anything like that for writing.

And, I legitimately hurt myself running in a way that rest would help. It was not an excuse. The work I needed to do was to rest. Perhaps that was the same with writing—maybe I needed a rest. That does feel like more of an excuse to me though.

I also have an app that I care about that can only be used if I run. My programmer identity forces me to run in order to program.

But, probably more importantly, I belong to a running group with a coach. It’s harder not to run than to run. There is some accountability there, but that’s not what helped me restart—it was my coach making a specific plan to restart that helped. She had been in my position many times and could help me through it.

So, what could I do to make sure I keep writing? I think two things are clear

Get a coach.
Have some kind of feedback mechanism.

My main issue is that I don’t really have a goal beyond just doing it to do it. I thought that would be enough, but I think I could use a little more.

I choose not to quit

THOSE WHO WOULD MAKE ART might well begin by reflecting on the fate of those who preceded them: most who began, quit.
– Bayles, David; Orland, Ted. Art & Fear [amazon affiliate link]

I began this year with the intention of writing here everyday and for 6 months or so, I found it easy.

And then, life got in the way.

In my case, it’s not bad news. I took some time off to travel in the COVID dip in June/July and got to see family and friends that I hadn’t seen in a year or more. And, I started getting interesting projects with deadlines and expectations. I don’t think it should have totally derailed me, but it did.

But, I’ve come back to some kind of equilibrium now. Or maybe it’s just the normal ebbs and flows of energy. I pride myself on having discipline and not needing motivation, but that only works most of the time. Not all of the time.

In any case, I choose not to quit.

Aim a Little Higher in your Whitepapers

I recently handed over my email to get a “whitepaper” that looked interesting from a company that had been recommended more than once as having an interesting product. I was kind of shocked at how shallow it was.

It was not just a crummy commercial — I think I would have preferred that though. I don’t mind being sold to if it’s done well.

I remember writing these kinds of things for Atalasoft, and it’s tough. I found one of my old ones that tried to teach imaging to prospective customers.

There are things in there that are simple, but my intent was to make the reader into a somewhat advanced user of imaging products with a deeper understanding. It’s kind of implied that our product could help them do these things, but they were free to try to do it themselves or use our competitors. I was betting that they’d give us a shot and we’d win on the merits.

I knew from talking to customers that these things were not obvious and not knowing them was making their use of our product limited. We could help them more, but they didn’t know what to ask for. The whitepaper was written to get leads, but I sent it to customers too when it was obvious it would help them.

As a test, put the first few pages up for free and see if you still get emails for the rest.

Outcome Story Templates

In yesterday’s post about Outcome Stories, I don’t think I quite got the story right.

I suggested changing the story from “As a writer, I want to publish posts, so I can share it with readers.” to “To get readers, a post must first be published.” I do think this does put more emphasis on the goal because it’s the first few words of the story.

But, it would be better if it were the subject of the sentence. The subject is what we’re talking about, and in my fix, we’re talking about the post, not the outcome.

So, tweaking it more, you could say “Getting readers requires that the post is published.” Maybe this is semantics. The more important thing is that the goal is early in the sentence, but if it can also be the subject, it will carry more weight.

But, if we go down this route, maybe we can develop a template around it

[Outcome] requires [the object] to [have a state]
[Outcome] requires [the persona] to [do an action] to [an object]
[Outcome] requires [the persona] to [do an action] to [an object] when [a trigger happens]

So, we end up with: “Getting readers requires the author to publish the post when they are done writing it.”

And again we’re clear that this is necessary, but not sufficient to accomplish the goal.

Outcome Stories

User Stories are centered around the user persona, which seems like a good idea, but it would be better if they were centered on a business outcome.

Consider the Publish button in WordPress.

One way to write a specification for this is to mock that screenshot I pasted above in Figma and say what the button does when clicked. Perhaps you’d use the typical User Story format and add “As a writer, I want to publish posts, so I can share it with readers.”

That works well in the sense that the production software will probably do what was specified. But, we’ve lost an opportunity. The story is focussed on a persona, but doesn’t emphasize the goal. I’m not even sure the persona matters at all here.

And just like no one wants a drill, I don’t want to publish. I want to influence readers. Others might want ad revenue or newsletter subscribers or to sell books. So, can we take the opportunity in this story to remind everyone about the business goals? The final state is not a published post.

It seems like a small tweak, but I’d word it “To get readers, a post must first be published.”

And now it’s obvious that this is insufficient. Yes, we need a Publish button, but that won’t accomplish the goal. This wording begs for more features to support the actual goal. It also implies that the metric for the success of the Publish button is the number of readers not (for example) the number of published posts. How would the design of publishing in WordPress be different if it was centered around the business goal of the users?

Publishing should lead directly to distribution, but in actual WordPress, the end of the publish step is a button to copy the link.

I guess I’ll go tweet it myself.

Sell Your Learning Plan, Not Your Roadmap

The reason software companies adopted agile practices was so that they could adapt their roadmaps to whatever they learned along the way.

If you learn something and do not change the roadmap, then there was no point to learning it. You might as well be doing a waterfall process. I think everyone accepts this. After all, waterfall is a myth. No one really thinks that the roadmap is set in stone.

But the business needs to plan. Marketing has events that need lead time to develop messages and material. Sales has prospects that want to know where the product is headed. Support, Training, and the Documentation team need time to get ready for new releases.

Some of this can be solved by developing support material alongside product development. For example, an embedded Product Marketing Manager can be closely following the trajectory of the roadmap and be developing messages at the same time. Even better, they can be helping to shape the roadmap from insights they get from their customer engagement.

The hard part is what to do with prospects. If you’re Apple, you never talk about what’s coming until you are ready to sell, but most of us can’t do that. Our prospects will certainly have unmet needs, and if you know you are actively working on them, it’s tough not to tell them. But, what should you say?

The truth is you don’t know the roadmap beyond the next few sprints. You are actively hoping that you learn something that will change it. New information is highly correlated with innovation.

But you are not changing your mission as easily. You know which customers you want to serve and what jobs of theirs you want to help with. So, talk about that and not the specific features you currently think will help. And talk about what you do know is coming (if you want). Even in a learning organization, the short-term roadmap should be pretty solid.

Product Development might not be able to commit to exact features, but they should commit to a learning plan, and that’s the roadmap that is safer to talk about.