The absolute state of software

My girlfriend wants to watch a show called Deadliest Warrior.

According to justwatch.com, Deadliest Warrior is only available for digital purchase on Apple TV+. I have an iPhone, so I went ahead and purchased season one.

The way we watch digital content is through a Chromecast. This allows us to watch content on our Samsung television. Apple TV+ is the only media app we use which does not support Chromecasts. I have to assume this is by choice.

Apple TV+ does support Airplay, of course. Our television supports Airplay, but only when connected to a WiFi network. I have been avoiding connecting our television to a WiFi network to prevent it from connecting to the Internet.

Our options appear to be as follows:

Connect the television to our WiFi network and find a way to prevent it from accessing the Internet. This would allow us to use Airplay.
Replace our “Chromecast Ultra” with a “Chromecast with Google TV” which supposedly supports Apple TV+.
Buy an Apple TV device.
Obtain a pirated copy of the show.

My girlfriend wants to watch a show called Deadliest Warrior.

Software generations

At my first job I wrote long-lived software. I started that job ten years ago. The software that I wrote still runs today. It will continue to run for at least another decade.

At my second job I wrote short-lived software. I worked for that company for three years. Most software that I wrote for them lived for about eighteen months. As the company outgrew its software, the software got rewritten, replaced, or removed.

At my first job software outlived its authors. The members of my team have all left. Some to different teams, most to different companies. The software we wrote continues to operate.

At my second job authors outlived their software. I saw newcomers rewrite the work of their colleagues. I decommissioned services that I had created. I saw my work thrown away.

I have since started my third job at a small, fast-growing company.

What I see at this place is software written without consideration for the future. The authors have not considered the lifespan of the software. They have not considered the tenure of this company’s software engineers.

Software at fast-growing companies will tend to be short-lived. Requirements change at a rapid pace. Products evolve. Systems scale. What was important six months ago ceases to be. What was unimaginable a year ago becomes quite real.

When writing software in such an environment make it quick and easy to rewrite, replace, or remove.

People at fast-growing companies will tend to be newcomers. They won’t have your knowledge of company history. They will need to be productive before they completely understand the software. They may never completely understand the software before it ceases to exist.

When working with such people make your software simple and explicit.

Doing these two things is not particularly difficult. It requires writing software in a certain style. That style is very achievable, even when moving at the pace required by a startup. The challenging aspect is maintaining that style over time, as people join and leave.

A giant pile of rocks

There is a giant pile of rocks. It is in an inconvenient location. A leader directs you and a small group of others to remove the rock pile. You have no equipment. The only option is to pick up a rock in your hands, carry it to a nearby hole in the ground, then throw it in. So that’s what your group does. Every day.

Time passes. You make progress, but not enough. The rock pile is smaller, but still inconvenient. One day a new person joins the group. They are an expert rock-pile-remover. They have a lot of experience removing large piles of rocks. On arrival, they look around and start making comments.

The expert points at the large pile of rocks. “This pile of rocks is far too large. It is in an inconvenient location,” they say.

The expert points at a small pile of rocks that is halfway between the large pile and the hole. “That shouldn’t be there. Those rocks should be in the hole,” they say.

The expert points at one of your group balancing a rock on their shoulder as they walk to the hole. “It’s more efficient to cradle the rock in your arms and hold it close to your chest,” they say.

The expert directs their attention to the rest of the group. “We should be using heavy equipment to move these rocks. We would be able to move the pile a lot faster if we had heavy equipment,” they say.

Time passes. The small pile is a little closer to the hole. The large pile is a little smaller. You still have no equipment. The expert rock-pile-remover has left the group. “They have no interest in removing the rock pile,” they said.

How I prototype browser games

I’ve been prototyping browser games recently. Here’s my approach:

Sketch out every screen in the game on paper. Map out the flow between screens.
Create rudimentary versions of every screen using basic HTML. I limit the resolution of each screen to 1280×720 and disable scrolling. Resist the urge to do any sort of styling or complex layout design at this stage.
Turn each screen into a static React component.
Move any variable data into props on each React component.
“Lift state up” as discussed in the React documentation. At this point I have a function which can render a single “frame” of my game.
Implement state transitions in functions outside of React.
Wire the React components up to those state transition functions.
Implement screen transitions in React.

At this point I have a functional prototype. I can iterate on the gameplay until it’s fun (or until I give up). The code is very simple: usually one HTML file and two JavaScript files. This approach allows me to avoid art and design (my weak points) and focus on gameplay and programming (my strong points).