Re-learning to code

I chose to write an online billing application. I’d written an invoice application in VB many years before to create the invoices I used for IT contracting. My intention was to create something on the web, that would replicate a Windows application in its style and workflow, and employed state management to give the visitor a good experience.

learning to code API controllers secured via OIDC Tokens. Database access via Entity Frame (EF) and hosted in Microsoft Azure together with Azure Functions, MessageLabs SMTP & Stripe Payment integration.

Version 1.0.0 of Envoyce was created a year later in 2021, and never got out of the testing phase. It was beset by architectural cul-de-sacs that I hadn’t foreseen or had the acumen to fix at the time. Writing what seemed like a straightforward & linear application was considerably harder than envisioned when I started.

One of the benefits (or hazards) when writing your own project, is that you only have yourself to blame. Understanding a particular coding framework or language is not enough. Getting a grip on a workflow that is suitable for your intended audience is critical. You really do need to “know your customer”. Twenty years of software development never prepared me for this. The art of making something “simple” is an exquisite balance that typically involves an enormous amount of logical automation behind the scenes. Something as rudimentary as putting up a form to capture data, is rendered complex when you only want to ask them one question and derive meaning from that answer. Creating an interface that follows convention but allows for shortcuts or customisations can be a delight when you get it right.

So, you test, test and test again. It seems that however long your testing phase is, or complex your testing strategy, you never can get a handle on every single permutation that exposes a “funky” behaviour. Indeed, many of the “bugs” are not bugs at all. These bugs have been coded that way because we (err I) didn’t understand the problem. To compound the issue, after a long development you can forget how something is coded that you wrote 15 months earlier.

Version 1 of Envoyce was thrown out and I went back to the drawing board without releasing it. I set about creating Version 2 and poured into the design and architecture all that I had learned from Version 1. I went through thousands of lines of code ripping out redundant methods & functions that just didn’t work very well and re-wrote them. I re-imaged the “me” interface into something more conventional whilst trying to maintain some of the Version 1 wins & magic.

Another year passed. Let me tell you something. Complex for a developer is straightforward. Complex is great. Easy… on the other hand is a different beast. Easy is never easy. Easy is super complex. Next time you see a super easy interface, believe me it won’t be under the hood.

One of the biggest changes in Version 2 was to make Envoyce free. Gone was the subscription model that implied value & support, and in came the “freemium” model with a zero (or close to it) barrier to entry. I won’t make any money out of Envoyce but I can say it’s been a hell of a ride. Every developer should attempt it. I’m definitely a better developer because of it. My approach is different. I hope that I’ve gained a 360-degree understanding of the development process.

I would proffer that anyone attempting to write an application from scratch do one thing. Understand what it is that you are doing from a workflow perspective. Forget groovy solutions or crowd-pleasing graphics. Get the basics rock solid before writing one line of code.

Envoyce Version 2 was released in April 2024.