Category: Development

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.

How I prototype browser games

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

  1. Sketch out every screen in the game on paper. Map out the flow between screens.
  2. 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.
  3. Turn each screen into a static React component.
  4. Move any variable data into props on each React component.
  5. “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.
  6. Implement state transitions in functions outside of React.
  7. Wire the React components up to those state transition functions.
  8. 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).