Category Archives: Software Business

The James Bond Opening

I am building software to help onboard sales team new hires by helping them get to demo proficiency fast (if you are interested, here’s a 3 minute video of the DemoWizard).

One of the things we help our clients with is writing a compelling opening. My partner, Brian, calls this a “James Bond” opening. I’m not a salesperson, but I gave a ton of demos at Droplets and Atalasoft (both made developer tools)—I wish Brian had told me this back then, because I love this kind of opening.

Here’s how I try to explain it:

The beginning of a James Bond movie is actually the end of the previous (unmade) movie. We don’t know anything about the back-story of that movie, but now we get to watch the most exciting 10 minutes of it until it ends. Then, we start the next movie—the one we came to see. We know that at some point we’ll see an ending that topped the one we just saw, so we lean forward in anticipation.

For you, the opening is your best customer success story, but just the end. That customer already have a completely set up system, and they are already getting value from it. Start your demo by showing the part of the software that delivers that value and share their results (with permission of course).

Now that you have their attention, you can start your prospect’s story and help them understand how they will get from where they are now to an ending like the one they just saw.

Don’t do Nothing and Be the Change You Seek

When I worked at Atlassian, we had five company values. The one that is most applicable to me outside of Atlassian is “Be the change you seek”. Even at Atlassian, in our slack, I probably reacted with our custom “Be the change” emoji annoyingly often. But, it wasn’t ironically—I loved that we (as a company and team) embraced the changes that people went out of their way to try to make. Co-CEO Scott Farquhar often started company Town Halls by telling new hires that they were hired to change Atlassian.

Before we were acquired, at Trello, we had a similar value we called “Don’t do Nothing”. It’s not exactly the same. “Be the change you seek” says that you should work hard to fix broken things you care about. “Don’t Do Nothing” was asking you to take a proportionate action to the problem, but not “nothing”—this could just be reporting it.

They both functioned in the same way with regards to who was responsible for improving the company—you were.

Be Happy When It’s Hard. Be Worried When It’s Easy.

When I was running product development for Atalasoft, I used to love it when a developer was having a hard time with a project. We sold image codecs, and our main competitor was open-source. Our secret sauce was that we could do things they wouldn’t. It was supposed to be hard.

If it were easy, everyone would do it, and it would be free. We wouldn’t have a business.

I think about this a lot when I see what people are doing with Large Language Models. Making an LLM isn’t easy, but Google thinks there’s no moat here for anyone. Still, it’s hard enough because it costs a lot of money, even if you know exactly how to do it.

The part that’s more concerning is what people who use LLM’s are saying. Everyone is so surprised how well it does with basically no work or skill on the part of the user. That’s fine, but then anyone could do it, and the thing they are doing with LLMs isn’t going to accrue value to them.

I think every knowledge worker should be using LLMs in some way, if only to learn about it. It offers enough benefits right now that it can’t be ignored. But, the easier it seems to be that you are getting good results, the more I would be concerned that you won’t be necessary to get those results in the future.

What Hardware Inspires Programming Language Design?

In early computing history, the government, academia, and industry collaborated to create languages for mainframes. The enduring ones were COBOL and Fortran.

You’d think that the PC era, when computing was delivering doublings in power every couple of years that it would also have been a time of programming language innovation. Aside from Microsoft, in the 70’s-2000’s, most of the PC companies didn’t do much here. IBM, Intel, AMD, Apple, Dell, HP, Sony, and Compaq made all the hardware, but contributed nothing to programming languages. Sun is the only hardware company that bucked this trend.

The photocopier, with Smalltalk, did more than the PC to drive programming language design than the PC. Fifty years of OO dominance followed.

But, for driving programming language development, nothing beats phones.

Telephone profits powered Bell Labs, which invented a lot of important tech, but some of the most enduring are the programming languages they developed. To limit it to just the ones I have used professionally, there are C, C++, Awk, KSH and the document processing languages troff, pic, and eqn. I’m probably leaving out about a dozen more.

AT&T was the most prolific converter of phone calls to programming languages, but Ericsson created Erlang, and Apple’s iPhone profits drove them to create Swift. You can give most of the credit for Kotlin to Android.

In the end, it’s probably money that does most of the work, and the real driver seems to be when it coalesces to a single winner.

Pre-define Your Response to the Dashboard

A few days ago, I wrote about using Errors Per Million (EPM) instead of success rate to get better intuition on reliability. I also recently said that Visualizations Should Generate Actions. Sometimes it’s obvious what to do, but if not, you can think through the scenarios and pre-define what actions you would take.

Here’s an example. This is a mock up of what a dashboard showing EPM over time might look like. The blue line is the EPM value on a date:

The three horizontal lines set levels of acceptability. Between Green and Yellow is excellent, between Yellow and Red is acceptable, and above Red is unacceptable. When we did this, we thought about using numbered severity levels (like in the Atlassian incident response playbook), but we decided to use Green/Yellow/Red for simplicity and intuition.

We also pre-defined the response you should have at each level. It was something like this:

LevelResponse
GreenNone
YellowThere must be at least one item in the current sprint with high priority to address this until the level is back to Green. It can be deployed when the current sprint is deployed.
RedAt least one person must be actively working to resolve the issue and doing hot fix deploys until the level is back to Yellow.

The advantage of this was that these actions were all pre-negotiated with management and product managers. This meant that we could just go ahead and fix things (at a certain level) instead of items getting lost in the backlog.

When we created this dashboard, we were in the Red, but we knew that going in. We worked to get ourselves Green and in practice, we were rarely not Green. This is another reason to pre-define your response, as it becomes too hard to remember how to handle situations that rarely happen.

How I Use JIRA and Trello Together

I started using JIRA for issue tracking when I worked at Trello (at Atlassian), and I still use it now. JIRA does everything I need in managing software projects, but I never send people outside of my team to JIRA because it’s not easy for casual users. For that I use Trello.

I have a Trello board for each project I am managing that is meant to be a high-level summary of that project. It is useful for onboarding and getting its current status easily. It has links to JIRA, Confluence (for specifications), Atlas (for status) and Figma.

This Trello board is the first place I send a new team member to help with onboarding. If someone has a question in Slack about the project, I make sure that it was something you could find out on the board and then link them to it there. The board is a kind of dashboard and central hub of the project.

These hub boards are curated, so I don’t try to use any automations to bring things over. If I think you need more information, I send you directly to the source.

JIRA is useful to the people that work on the project every day. I use Trello for those that just check in weekly or monthly.

Visualizations Should Generate Actions

Yesterday, I shared a heatmap visualization that I used to target manual testing time. I chose a heatmap to show this data because you can tell what you need to do just by looking at it.

In this example

A heat map the test status of iOS devices across different features in an app

It’s pretty clear that you should get an iPhone 13 with iOS 15 on it and start testing everything. You could also explore board creation on all devices. If the entire heatmap were green, you would know that you had probably covered most areas.

It would be easy to write a program that took this same data and generated a to-do list instead. Maybe that would be preferable, but people like visual dashboards, and it’s easier to see the why behind the task if you have a sense of the underlying data.

But, that’s a big clue to whether your dashboard visualization works. If you could easily generate a to-do list just by looking at it, then it probably works. If you look at your dashboard and have no response, it might look pretty, but it’s not doing its job.

Use Heatmaps for iOS Beta Test Coverage

At Trello, I built a simple visualization for understanding coverage of our app during Beta periods. We used Mode to analyze data, and so I used their Heatmap.

Here’s a recreation in Google Sheets:

Along the top was each device family and OS. Individual devices were grouped based on how likely they were to be similar in testing (based on size, version, etc). I used this list of Apple device codes (which were logged with analytic data).

Along the left side were the most important screens and features. It was a much longer list that was generated from analytic categories.

The center of the visualization was a heat map based on how much usage that feature got on that device (at the cross-section) normalized against how much usage it got in production. So, if a cell was green, it meant that it was tested a lot when compared to how much it was used in production. If a cell was red, it meant it was under tested.

Often, entire vertical columns would be near red because the combination of device/OS wasn’t used much by our beta testers. So, we could direct our own efforts towards those devices and turn an entire column from red to green.

We also made sure new features would get their own row. These could also be red because beta testers might not know about them. We could similarly target those areas on all devices. These features could not be normalized against production usage (since they were not in production yet), so we use a baseline usage as a default.

Mode kept snapshots of the heatmaps over time. We could watch it go from nearly all red at the beginning of the beta period to more green by the end. I can’t say we could get the entire heatmap to be green, but we could at least make sure we were testing efficiently.

Just Started a New Software Engineering Job? Fix Onboarding

If you are about to start a new job as a software engineer, the way to have a big impact day one is to go through the onboarding with the intention to generate a list of improvements that you work on over time.

Here are some things to look for

  1. Incorrect or outdated information. If you find these, just fix them as you find them.
  2. Missing entry-point documentation. Even teams that have good documentation often do not have a document that is useful if you know nothing. Often they don’t go back and make a good “start here” kind of document.
  3. Manual steps that could be scripted. Don’t go overboard, but if you see some quick wins to automate the dev setup steps, it’s a good first PR. It’s a tech debt payoff that is timed perfectly.
  4. Dev Setup Automation bug fixes. If anything goes wrong while running the scripts to set up your machine, fix the bug or try to add in any detection (or better error messages) that would have helped diagnose the issue.

There is usually a lot of tech-debt in onboarding code and documents because no one really goes through them. Sometimes underlying things just change and tech debt happens to you. You are in a unique position to make it better for the next person and have some impact right away.

WWDC 2023 Wishlist

WWDC23 is next week, so I put together a wishlist. I last did this in 2021, where I broke it down to watchOS, iOS, and developer tools. Whenever I write these wishlists, they are very centered on the work I am doing in the moment and what I need to help me. This year, I am doing less Apple device development, but I use the devices a lot and here are the things I am thinking about.

Headset

There are a lot of rumors that Apple will release an AR/VR headset. It seems like it will cost about $3,000, have an external battery pack, and come with a new framework.

This rumor has been around a while. For the Fall 2021 Apple event (when we really thought a headset would be coming), I wrote:

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.

So, while I do have development ideas for an AR headset and would love to try one while running, it’s not worth $3,000 for me. If it’s a gaming device, I am not interested.

If the headset could somehow help me in my work (make me a more productive software engineer), then I would be more interested. GitHub Copilot seems to do a good enough job just in VSCode’s interface, but I could imagine being immersed in a VR world with even more heads up information. It would be interesting if there is some kind of meeting space VR, but since I mostly work alone, it would not be worth it to me.

I continue to be worried about headsets that have cameras. I think that it’s inherently creepy out in the real world and dangerous if camera access is extended to apps. I wrote about some ideas for Socially acceptable cameras in AR that I hope are in this headset if they are meant to be worn in public.

New Mac Hardware

If they release new hardware, I am in the market for a new MacBook Air. I love mine, but it’s an M1, so it only has 16GB. I wouldn’t mind expanding on that. I am holding out for a better camera. This seems impossible in the razor thin lid of the MacBook Air. I would be ok with some kind of camera array and a notch, if that’s what it took.

watchOS

My watch needs are driven by my app, Sprint-o-Mat. Aside from the AR features I mentioned above, I am pretty happy with where it is right now and don’t think there’s anything more I need in watchOS for it.

iOS/iPadOS

I hope that Apple adds more safeguards against device theft. One thing they could do is autolock the device if it moves out of connection with the watch. And they obviously need to do something about the fact that the device password gives too much access to iCloud and the Apple ID.

As for a system-wide feature, the biggest thing I miss on iOS is a clipboard manager. Even if they just kept a clipboard history and exposed an API, so that apps could fill the gap, I would be satisfied.

tvOS

I have an Apple TV, HomePods, and my wife and I both have AirPods (all made by Apple). But for some reason, the Apple TV insists on being connected to the TV audio by default. There seems to be no way to get to stay on the HomePods.