Let’s talk about custom code solutions! I’m going to talk about the process of building an app and then what it requires in terms of on-going maintenance.
But first, let’s get some background info here that’ll help provide some context as we proceed. I want to introduce you to Github. This is a very widely used website both by private individuals and by corporations to manage source code. What it does is provide a place to store and manage the source code for an application. It isn’t just a dumping ground for code, though. It does a lot of things, like allow people to work on the same part of the code at the same time without interfering with each other (branching) or allow other people to review changes that are going to go to production (pull request or PR). But the important thing that I’ll be using in today’s post is history.
When I make a change to code, I can assign it to a “commit”. This commit is then added to the history of the project. It’s how we build a timeline of everything that’s changed, plus some notes for context. Commit messages can be whatever you think is helpful – but there’s also a lot of “wip” and “oops” or profanity or my personal favorite: “my cat walked across the keyboard” which will live for eternity in my last employer’s commit history. Because once that commit is out there, unless you do some really weird hijinks that no one likes doing, it’s there forever. This is really handy when you’re working on a large project with a storied history of changes… or when you’re writing a post like this one and want people to visually see the work that’s gone into the Portals.
So let me show you the history of the Peerages Portal and the Arts and Sciences Portal.
Some quick stats here.
The Peerages Portal has 554 commits and was created in 2017. The A&S Portal has 208 commits and was created in 2019.
It’s hard to say how much work goes into a single commit. It really depends. Some changes take a matter of minutes. Others take days, if not weeks depending on complexity. Let’s look at some examples here.
First up: forcing people to register with their SCA name. Oh look. It’s a one-line change. https://github.com/…/201388f811a4390aa656e772133dd3b3ee…
Allowing judges to define what categories they prefer to judge. 23 files changed with 194 new lines of code and 38 deletions. https://github.com/…/df6deecf5a473381ae0c64ded6405a351a…
So as we’re talking about this, just keep in mind that the amount of work that goes into any given feature is highly, highly situational. I also don’t want to make this sound like more work than it really is, because 23 files changed sounds scary, but it’s not that unusual. That’s just kind of the nature of the beast. That’s why we use patterns that are easily recognizable. For instance, I didn’t write the Peerages Portal, but because it adheres to those patterns I can immediately find my way around in it and troubleshoot it if necessary.
But let’s talk about what it takes to get us to this point of a working app. If you’ve hung out with me, especially if I’ve had a drink or two, I’ve probably said something along the lines of “I could smash my face against the keyboard and a web app will fall out.” And it’s true! I’ve created and deployed web apps in a few hours before. The reason for this is those patterns I mentioned earlier. They’re very very formulaic, to the point where most modern frameworks can generate boilerplate for you. It’s fantastic for getting a proof of concept onto the web very, very quickly. Let’s take a look at an early commit on the A&S Portal.
Holy shit 45 changed files with 587 additions and 132 deletions??? Well, to be honest, I didn’t actually write almost all of that code. I generated it. The generator did all the work. However, this is only a skeleton to build upon. Let’s say that you want new garb. You go to the store, you buy fabric, you download a pattern for the cool new surcoat everyone is wearing. Are you done? Hardly.
Programming is the same way. We can use generators to create a lot of what we need, but keeping with the garb example, if you put that surcoat on and go to an event with it, you’ll quickly discover that it’s only held together with safety pins and isn’t going to be able to do even remotely close to everything you need it to do.
So that’s how we get to 200-500 commits of work over the course of years. Every time something comes up that isn’t included in the generator (which honestly is most feature requests), that means going in and changing things.
Whenever you think, gosh it’d be nice if we had a web app that does x, y, and z: this is what you’re looking at. A lot of generated code that then needs days, if not months, worth of work to make it do exactly what you’re thinking. The A&S Portal had a whole team of people that met every other week (if I’m remembering correctly) for months to make it a reality.
But it gets worse. And we’re going to get into some stuff that I’m frankly embarrassed about so be nice to me please.
Apps require on-going maintenance. Yes, technically you can leave them alone for a long time and they’ll keep chugging along if they were designed correctly, but at some point your neglect is going to catch up with you. We call this ‘technical debt’ and at some point, that debt is getting called in. For the A&S Portal, that debt got called when our host was like ‘nah, we’re not supporting this version of Ruby anymore, upgrade or die lol’ and I had to spend my free evenings for about half a week figuring out how to go back and merely upgrade everything I’ve been neglecting.
If you’re wondering why we have to upgrade, it’s because things change a LOT in the open source world. That’s just how it is. And most of the time, it’s security vulnerabilities we’re addressing.
Time for the shameful part.
I’ve been neglecting the A&S Portal for a while now. To my knowledge, it’s been running fine without me, which is great! That’s how it SHOULD be. But I know that the technical debt is piling up behind the scenes. Let’s talk about Dependabot.
But first, let me define what a “dependency” is. Programming builds on top of other programming so that no one has to start from scratch. When we use other code written by other people, that’s called a dependency. Think of it like a citation. Except instead of merely referring to someone else’s work, you are including it in the building blocks of your paper, and without it your entire paper collapses and stops being a paper. It’s now a 500 Server Error and people are messaging you like “hey Brighid I think the portal is down.”
Dependabot is Github’s answer to how lazy programmers are. It’s a bot that scans your code and if it finds dependencies that need to be updated due to security vulnerabilities, it opens a PR on your repository for you. All you have to do is merge it and deploy it. Right now, the A&S Portal has 8 open PRs from Dependabot… which is honestly a lot fewer than I expected. But why haven’t I just merged them into the main branch and be done with it?
Because I need to merge them. Then test them. Then deploy them. And if I’m really unlucky… I might discover that I’ve neglected this long enough that some things are not compatible with each other and now we’ve entered what I fondly call “dependency hell.”
I will never forgive Pinterest for releasing a dependency that we pulled into our project and later got my team at my last job stuck for a MONTH because of dependency hell.
And sometimes the tech debt comes due in really weird ways. Want to know the last issue we had to deal with? Literal government legislation. Yeah. Seriously. There’s some legislation out there around emails and we had to figure out how to comply with it because our host was like ‘lol get wrecked if you don’t’. Stuff comes at you out of left field and there’s no way to predict when it’s going to happen.
The only way to deal with tech debt is to stay on top of it. Again, the amount of work that this is, is “it depends.” Sometimes your garb just needs a quick stitch under the armpits and sometimes the entire seam comes undone. But what I really want to stress here is that a custom coded solution like the Portals is not something you can write once and then you’re done with it. It’s a long-term commitment. My Portal has literally lasted longer than my officer term did. If you think a 3 year commitment is a big deal, take a look at when the portals were created.
Again, I don’t want to exaggerate how much work these are. I’ll be real – my portal was a LOT of work to build initially. If I spent that time on garb, I’d probably have Landsknecht by now instead of a pile of fabric, dreams, and self-doubt. Heck, I might have two Landsknecht outfits. It’s hard to say since I haven’t finished even one yet. But now that it’s built and running, I have been neglecting it for almost a year now and it’s been fine. It’ll probably be fine for a few more years. It’s just I know in the back of my head that the moment someone asks for a feature or something breaks… all that tech debt comes due. And so long as that portal is up and running and being used… then I have a responsibility to maintain it.
I want to elaborate a little bit on the reason I put this post together as I got too focused on the tech side of things on my first attempt at sharing it. It’s very tempting to want a custom built solution to solve the various problems we face as a Kingdom. I’ve certainly been one of the people in the past that thought we could just code away all our problems and jumped at the opportunity to do so with the A&S Portal. However, time is the best teacher, and through my own experience and seeing what’s happened to other solutions, I feel we need to move away from custom solutions wherever possible. Basically, use tools that are already out there and don’t require a programmer to volunteer their time and keep volunteering their time throughout the entire lifespan of the app. So this post was meant to demystify some of the process and explain what is being asked for with a custom app.
-Brighid
Deputy Webminister
MK Helpdesk Team