Overthinking Design

 

I tried really hard to draw Rodin's The Thinker.  This was the best I could do.

I knew going into my financial app adventure that it was likely to be overdesigned.  I already have a spreadsheet that functions well enough, so by definition, any other functionality is extraneous (unless you're Apple, which has the evil genius ability to convince us everything we've ever known about a computer is wrong, even if we previously had no issues whatsoever).  But software development, in many cases, is rewriting variations of the same logic again and again and again.  And again and again and again.  Embarking on this project also gives me the opportunity to take various aspects of prototyping and see how far I can get in a reasonable number of hours.  If I ever want to take a dip in consulting to create prototypes for budding entrepreneurs, I can point to this as an example for scope.  

My goal for the project is to keep the total time at or less than 100 hours.  This allows me to charge a reasonable fee for both the client and myself without either of us being disappointed or exhausted.  I'll address some of the trade-offs of creating a prototype vs. a production app later when getting into the details of the project.  I will say, to date, things are going swimmingly.  I'm 37 hours in, have made two major architectural changes, and even undertaken a site redesign.  Not bad for a standard non-Elon Musk work week.

Here were my initial requirements:

• Monthly budget tracking via manual entry.  I left open the option to add Optical Character Recognition (OCR) to scrape screen captures or PDFs.  A few years ago, this would've been an exercise in futility due to myriad bank layouts, but with improvements in AI, this may have a fighting chance.  Still, this is something I could easily get sidetracked by, and is why it's currently optional.
• Categories for each entry.
• Budgets for each category.
• Dates for each entry.
• Accounts for each entry.
• Another option is to track the balance of the accounts to make reconciliation easier at a glance.  This, however, requires me to track account transfers, which otherwise clutter up my budgeting software.
• Net worth tracking.
• Recurring transaction tracking.
• Filtering by each of the above.
• Mobile first.
• Meets accessibility criteria.
• Each transaction should be easily editable, but shouldn't allow for easy accidental editing.

And that was it.  I'd originally envisioned writing the application in Python (Django) using a SQLite backend and, indeed, even started off with a few lines of code to do so.  

Then I realized I had a ready-made datastore in Google Sheets that I was already familiar with (this was the first major architectural shift I made about 2 hours into the project).  I knew that Google Sheets had an Apps Script utility that allows users to write additional functionality against their spreadsheets using JavaScript.  They also have the option to write doGet() and doPost() with rudimentary HTML templates to deploy a website using the spreadsheet as a simple database.

I'm always drawn to using the (theoretically) simplest solution.  Developers in particular have a habit of being drawn to the newest technology like moths to a flame, even if it actually takes more work to rewrite the app using the new technology without any notable benefits (and often regressions) than it does to maintain the boring existing solution.

So, I decided to use my ready-made data store and its trusty functions for accessing the data via the web.  For extremely simple processing, this is still the way to go.  Just code up a little JavaScript in your doGet() and doPost() functions, add some styling in the accompanying HTML template, and you've got yourself a little "Gone Fishin'" application.

But, for anything that takes even more than the smallest level of development, it has problems:

• There aren't a lot of good options for structuring the code, so it needs a lot of care and attention if you need to organize it in any fashion that doesn't resemble overcooked spaghetti.
• The rudimentary functionality also makes pulling in external libraries for productivity difficult.  Any library that can be included via a <script> tag in the HTML page header can be used, but it can't be optimized.
• The code as it exists doesn't lend itself to version control.  It will maintain deployed versions along with your sheet, but everything needs to be written and deployed live on the equivalent of the production server.
• There is a useful tool, clasp, that allows you to download your code and develop locally, so that you can store your revisions in git, but everything needs to be uploaded again to verify functionality.  If you're a developer, you know this is very tedious™.  You have to make a change locally, upload the new code, deploy a new version, and cross your fingers you didn't make a mistake.  It's like the modern version of 1960s debugging.
• Of course, you can get around this by creating local mock data, but now you're writing a lot of code to mimic functionality that may or may not work because you're just guessing at the internals of the functionality.  In addition, you're cluttering up your pristine codebase with a lot of code that's there just to help you develop locally, rather than swapping out environments locally like any good development system should do.
• You're relegated to using the version of JavaScript that Google dictates for its App Script, which is now updated to the latest version, but was using ECMAScript v5 for a long time.  I'm not picky about using something new and shiny, but I would like to use technology that was written sometime in the last decade.

With these obstacles in my way, I started looking for ways to utilize static site generators like Astro to reduce the amount of code I would need to run (and pay for) on the server side.  While casually browsing, I found a Reddit thread extolling the praises of Astro as a frontend for all backends, whether or not the site is static or an interactive application (also known in JavaScript land as Server Side Rendering or SSR).  Intrigued, I revisited server-side platforms that either had a free tier or very reasonable pricing for an application that may never actually make money.  I mean, I'm willing to spend some money on hobby projects, but not $20/month just because.  

Among the usual suspects - Netlify, Vercel, and Cloudflare, Cloudflare had the most generous free tier (as well as reasonable pricing for scaling up) and a blog post extolling the impetus behind supporting a generous free tier in perpetuity (sure, this can always be scuttled as many other free tiers have in the past, but the language at least seems a bit more sincere.  What can I say?  I'm a sucker.)

And now with my front-end - Astro, back-end - Cloudflare, and data store - Google Sheets - in place, I was ready to make my first earnest effort in yak shaving.  Gory details to follow.

Until next time, my human and robot friends.