Burning the House for Better Nails : Rewriting @threespeak's backen...

There are days when I doubt the roadmap, so to speak. Not because I think I’m necessarily going in the wrong direction, but because I wonder if I’ve made things harder for myself for no apparent gain.

Only those who follow these devlogs closely (there may be one living being that does) know that I’m working on revamping—yet again—the backend for Hive account@threespeak. I’m not doing this because the current system isn’t working. It is, more or less. But in hindsight, there are elements of the legacy code that could be improved. And sometimes, rewriting makes more sense than fixing.

direct jobs.png

For those not into code, I imagine this sounds absurd. Like burning down a house just to reuse the nails. It doesn’t make sense at first glance. But, believe it or not, that was once a real practice.

The current flow we use on Hive account@threespeak has, at least in my opinion, several weak points. For one, it requires posting authority from users, which can be a deal breaker. On top of that, core functions—like scheduling, manual posting, and publishing to Hive—are handled through a collection of scripts.

These scripts are triggered by cron jobs, which is just nerd talk for: they run on timers.

What I’m building now is a more loosely coupled design. In practical terms, this means that any front end—not just a video platform—could interact with it. That alone is a win I didn’t fully appreciate when I started this rewrite. But more importantly, it would turn Hive account@threespeak into a true Hive front end, rather than something adjacent to it, as it is today.

I’m aware this might only make sense to me, but I can defend the point.

I also know better than to make big changes in one swoop, and truth be told, I’m in no rush. As I said, things are working. But once the switch happens, almost everything I’ve built will need revisiting—from the encoder to the monitoring tools. Calling it a “major refactor” is like calling dirt… dirty.

But the big “why” is what matters most.

We’ve made it a goal to turn Hive account@threespeak into a business. A goal that, I’ll admit, only recently started to feel achievable. When it’s all said and done—and that may still take a few months—not a single line of legacy code will remain. More importantly, we’ll be able to reorganize our hardware and allocate resources far more efficiently.

Still, this process will be slow. It has to be.

Like that old video of people moving an entire building, inch by inch.

-MenO

I reckon that sometimes taking a piece of code and re-doing it from the ground up is the right decision. It can prevent unexpected problems further down the line.

In one of my previous roles, I had the (rather B.S. ) title of "Change Implementation Manager". What that really meant was that I was the gatekeeper between business departments and a very overworked and under-resourced IT department. It was a nightmare of cost-cutting combined with a sales department who thought that I business case meant throwing a big enough tantrum to get poorly scoped work done "because the customer wants it".

All that pressure meant that the poor IT guys had to take shortcuts. In particular, they'd point routines at bits of pre-existing code that did the job they wanted, rather than including the code in the discreet module they were working on (sorry if I'm not using the right terminology.... I was on the business side really, not an IT specialist at all !). Then, when the team on the other side of the world which really owned that code that had been hooked into made changes or decommissioned it, unexpected things would break all across the business.

Twice while I was there the company had failures so bad that they had to go back to pen and paper for several days. When the business finally folded, the official line was that it had been a ransomware attack so bad that it ate all their backups and they were unable to recover. But I suspect the reality may have been that their creaking code finally just gave up the ghost....

man you are full of anecdotes... speaking of ransomware. Many years ago now, I was in dire need of income, my crypto holdings were drying up, and Steem (that long ago) was in the verge of forking. I got a job in a kitchen cabinet making factory.

I got there, apparently, a month late. As they had a ransomware attack too, and had to pay in monero. I was able to help them secure their systems, but in the end those things happen due to user error.

i sure am no coder, but i get the empty ur cup philosophy. good decision. sometimes a fresh start is good..

It’s completely natural to feel that way sometimes. Doubt doesn’t mean failure—it often means you’re reflecting and growing. Even if the path feels harder, every step teaches you something valuable. Keep trusting the process; clarity often comes in the journey, not just the destination.

The key is to address potential inefficiencies in the code at their root, which is why I think this revamp will ultimately turn out well. Plus, what makes me happiest is the vision of making 3speak a true Hive front end : O

I trust in you, guys, as always making 3spk greater than ever : )

Refactoring code is always risky as you may not even know all of what it was doing previously. I hope you have good specs for this system.

There is a programming method where, after you finish coding and testing, you take the lessons and knowledge you've acquired and write it again from scratch. I haven't tried it yet, but it has its merits. If your testing was high-level and automated then it can enable "fearless refactoring".

i need to learn about this method... sounds awesome

I never got the name for it. After consulting an AI, I guess it would be Greenfield in what you are doing, while using it as a part of the main process maybe Throwaway Prototyping. Needs a better name, I think. I read it as part of an agile document.

To keep the functions up to spec, Behaviour Driven Development (BDD) would fit well with it because the tests are human-readable. In Java, I've used Cucumber. I read that there is a javascript version.

adding functionality always require changes , but making changes backwards compatible isn't always easy or possible so it does make sense in a way .