Design on Jesse Builds Software

User Experience for Background Processes

Sat, 07 Mar 2026 10:59:00 -0800

Done well, background processes are a fantastic way to save time, and more importantly, save focus. Handing off monotonous chores so you can do something more challenging can be a true relief. Unfortunately, background processing isn’t always implemented well. When it’s done poorly, it can undermine trust in the system.

A lack of trust can have negative effects beyond just making people miserable. It can discourage exploration and discovery. It can force painful and inefficient workarounds. It can also cause data to be duplicated, forgotten, corrupted, or lost entirely.

Disambiguating Scalability

Fri, 09 May 2025 19:33:22 -0700

Although it was years ago, I still remember the conversation vividly. I was having my regular check-in with the CTO. It was also sunny outside, and the view from his office was particularly nice that day.

He asked me, “Is our app scalable?” After a moment of thought, I answered, “Yes.”

I spent the next few years remembering that conversation, wondering what would have happened if I had asked what he meant by scalable.

Abandoning Household Organization

Mon, 04 Nov 2024 07:02:12 -0800

I have been trying to improve the organization of my household for years. My wife and I have been using shared Google calendars for over a decade, but there are plenty of issues we could still improve. It was only minor challenges when it was just the two of us, but once we had a child, the systems we had started to show their limits.

I quit my job with the dream of building my own product, but I started without any particular ideas about what to build. It didn’t take long before I was considering working on this exact problem. Not only was it something I would benefit from, but it was also something I would find interesting, and could enjoy building and maintaining by myself.

Rocketbook vs Whiteboard

Tue, 06 Aug 2024 22:24:33 -0700

I have always liked using whiteboards. They are a great tool for communicating, but also great for exploring thoughts and stimulating creativity. There are computerized equivalents, and they have their advantages, but I’ve never found them as effective because I get distracted too easily. I can spend more time fiddling with the lines and colours than working on my actual problem.

I like whiteboards so much that I bought a stack of them, and an artist’s portfolio bag to carry them around. I imagined popping out a few drawings at a meeting, or handing boards around for a creative session. I still love the idea, but in more than twenty years I’ve never even taken them out of the house.

The Pragmatic Potato Tech Stack

Mon, 24 Jun 2024 12:02:43 -0700

I recently launched my new company, Pragmatic Potato Software Inc. The creation of a company itself is pretty easy, but setting up everything you need to do business can become overwhelming quickly. There are a lot of compelling options available, each promising the moon. It’s not that simple though.

I’m going to be writing about the technology stack I’m using to run my company, and why I made the choices I did. There is a lot more to a company than its technology, but I’m not an expert in setting those up.

Cross-Cutting Concerns - Ten Approaches

Mon, 27 May 2024 13:18:08 -0700

One often (and ironically) repeated rule in programming is: don’t repeat yourself. We repeat it so much we even have an abbreviation: DRY. There are good reasons for this advice. Duplicating and modifying code can be a quick and easy way to get a feature done, but it can also lead to problems over time. It’s harder to understand code when the valuable logic is mixed with reams of low-value boilerplate. Subtle differences can also sneak in, leading to inconsistent behaviour across the application. Things get even more difficult if you want to make a change.

The True Cost of Dependencies

Wed, 27 Mar 2024 15:35:10 -0700

I used to use Getform for a contact form on my consulting company website. I recently received an email from them announcing that their free tier was dropping from 50 submissions per month to a lifetime limit of 25. This makes it useless for anything more than a trial, and their lowest tier is a more expensive than other similar options.

I’m not here to complain about companies taking back free offerings. I don’t like the change, and I wish they’d given me more than three days of notice, but they are a businesses, and businesses need to make money. It is a good reminder though: even if something is free to use, it still takes time and effort to integrate, to maintain, and you may occasionally need to throw it out and find a replacement.

Using Architectural Decision Records

Tue, 21 Nov 2023 17:51:51 -0800

Architectural Decision Records are a simple technique that promotes good architectural thinking and better collaboration. They don’t need to be big or complicated to be effective, but they do take some time, and are yet another step between setting goals and delivering value. If you use them in the right circumstances they can be a big help.

What is an Architectural Decision Record?

An Architectural Decision Record (often abbreviated ADR) is just as the name implies: a document that describes an architectural decision. It can include various details, but should at a minimum describe the problem being solved and the solution that was chosen. It can be a simple text document with a page or two of text, or it can be longer with specific sections that are important to the team.

Getting Unstuck Without a Rubber Duck

Tue, 03 Oct 2023 18:03:27 -0700

Building software is a mostly creative endeavour, and as such, it sometimes resists progress. No matter how hard you try to push forward, if you are truly stuck, continuing on the same path is unlikely to work. Fortunately, there are a few different tricks you can use to get going again.

Take a rest

The easiest way I’ve found to get back on track is to take a break. When in the office this was often making a cup of tea or eating a snack in the break room. It could have been a ten-minute walk around the block, but if I’m honest, I have rarely tried this.

Choosing Powerful Names

Mon, 18 Sep 2023 12:44:36 -0700

A junior developer needs to strengthen their technical skills to advance. An intermediate developer needs to strengthen their organizational skills to advance. Senior developers need to master these and also demonstrate that they can move multiple teams forward together. Influencing people (and especially developers) is no easy task, but a positive reputation can do a lot of the heavy lifting. One of the easiest ways to amplify your reputation is to put some extra effort in when choosing a name.

My Architectural Report Template

Tue, 08 Aug 2023 12:45:13 -0700

As an architect I’ve been asked to answer a lot of hard questions. I used to waste time figuring out how to structure my answers, preventing me from getting into a good flow sooner. Now I have a simple template that is easy to use, easy to read, and saves me that wasted time up front.

This template works for simple reports that are only a couple of pages, but can easily be adjusted or expanded for more complicated or much larger documents.

Design by Dogma Antipattern

Sun, 30 Jul 2023 13:41:17 -0700

Always use a NoSQL database so your app can scale.

NoSQL databases can be more scalable, but schema-on-read has other drawbacks. NoSQL databases are much less capable of transactional changes. Relationships are difficult or impossible. Designing schemas to be efficient is much harder, and requires more up-front knowledge about your problem. NoSQL databases are sometimes the right tool for the job, but they are not the right tool for every job.

Sustainable Errors

Mon, 29 May 2023 09:57:05 -0700

Making a program work for the happy path is not always easy, but given enough time I believe pretty much anyone could do it. When a professional takes on the task however they will make it work for more than just the happy path, and do it with code that is easy to debug, and easy for others to understand and change. Since so much of what we end up dealing with are exceptional flows, we need a concise way to deal with them. Fortunately we have the aptly named exception pattern.

When to Add an ORM Tool

Mon, 03 Jan 2011 12:33:03 -0800

I’m working on the code that parses VCalendar data so that it can be processed. I’m copying the data I care about into a simple data structure that can represent a calendar request in any format. Any logic that interacts with calendar requests would use this internal structure. I want it to be simple, only having the stuff that I need, but I don’t want to completely re-invent the wheel either, so I will use the VCalendar format as a guideline.

Invitations and the VCard Format

Thu, 16 Dec 2010 12:59:22 -0800

My next goal for the Themis project is to parse an invitation from an email. I am starting with invitations generated by MS Outlook because that’s my target audience, but a peak inside of a Google Calendar invitation gives me hope that I’ll be able to support multiple calendars without much trouble.

Outlook invitations are sent in the VCalendar format, content type “text/calendar”. The standard was published as RFC 2445 in 1998. It describes a standard layout for calendar data in the VCard format, which is described in RFC 2425.

Themis: System Design

Tue, 14 Sep 2010 22:29:40 -0700

I’m charging forward on the Shared Resource Schedule Service. There are a lot of things I’m getting into place before I start writing code. Don’t try to tell me that I’m not being agile either, you always need to design a little to write good code. The key to being agile is designing only as much as you need, and being prepared to change your mind later.

The Name

The first order of business was to choose a name. It helps to know the name before you create a project. I’m also hoping to put the source in a public repository right away so that I can talk about the coding process while I build it.

Shared Resource Service Requirements

Sun, 08 Aug 2010 21:12:53 -0700

I want to start my project by dividing up the various things the system needs to do, then put them into the order I plan to approach them. I want to start with requirements that are the most risky and most important to success first, and work my way down the list until I finish with items that are neither risky nor important.

This approach gives me several advantages. It’s not an issue in this case since I don’t have any deadlines to meet, but if this were a professional project and a deadline had to be pushed up, I am more likely to have a product that does the most essential things. If I had a fixed deadline and the project starts running long, I’m more likely to have a working product that’s just missing a few less important features. In an ideal world those don’t happen, but at the end of the project the parts that were risky and/or essential have had the most time to be tested and fine-tuned as the application matures.