Side project of a side project

I’ve been working away building the Costs to Expect Service for a while and we are starting to make some real progress, before I started work on the next app for the service I wanted to test a couple of small ideas, enter my Yahtzee game scorer.

I released v1.00.0 of the scorer on the 3rd of August, the initial usable version was released on the 21st July. I worked on it for an hour here and there and quite quickly got it to a point where I deemed it featured enough to get a v1 label, it isn’t done but when is anything?

Building the scorer was freeing, I quickly tested some ideas and designs without having to worry about conforming to the design on the main Costs to Expect App. I discovered a couple of bugs within the API and also created new routes on the API to deal with requirements unique to the Yahtzee app, I suspect if I had ‘added’ the scorer to the existing App I wouldn’t have come up with the same design.

Looking at the API from a different perspective has been worthwhile, it forced us to rethink, rather than have a monolith App that is capable of everything, we decided to break everything up. The API is the core of the service and we are now going to have smaller focused Apps that can more easily be designed for there intended purpose.

The current App is going to be slimmed down to expenses only, a budgeting app is in the works and Pro versions of both will come along some time next year.

There are going to be more side projects of side projects, we have a few in the works. They have to take a back-seat for now as I need to get on with building the Budgeting app and I’ve a freelance project or two coming up that will steal some of my focus.

Jobs and tasks gamble paid off

I have spent the last 12 months developing a product for one of my long-term clients, I’m going to refer to the product as EWAQO for the rest of this post.

I initially thought EWAQO would be three to four months of work, lockdowns, homeschooling, the pandemic in general and feature creep put paid to that.

EWAQO is far from the largest product I’ve worked on, I’ve been a professional developer for over twenty years and have worked at scale, it is however the largest product I’ve created single-handled. The Costs to Expect API, Website and App are big when combined, EWAQO is in a world of its own, it has so many different systems and is immense.

I decided early on to go deep with queues and scheduled tasks, I wanted to keep the App fast for the user and do as much of the heavy lifting as possible behind the scenes. Typically, I’m using queues for complex user-initiated tasks/actions and scheduled tasks are for processing.

It is easy to handle the complex stuff behind the scenes, but there is a problem, you need some visibility. Before I wrote the first job I created the interface, that way the client can see what is happening, is a job running? Did it fail? What was the output? Who initiated it? etc.

This was the masterstroke and made so much of the complexity possible, the client could see what is happening, job classes and tasks are simpler to create because you don’t need to worry about the front-end, it all came together brilliantly.

I’m not done with EWAQO, as of writing, there are 27 jobs and 26 scheduled tasks and I have visibility of each one, I can see when they are running, what is due, when and why they fail, it all just works.

We are working toward the soft-release of Costs to Expect this year, part of that is developing two smallish apps that act as companions. Both apps will borrow heavily from what I learned developing EWAQO.