Renovating Your House

Of all the weird and wonderful analogies to building software that I’ve heard, the one that sticks with me is building a house. No analogy is perfect, and I’d love to see the Pub/Sub aisle at Home Depot, but it works well enough. The general contractor picks the right tools and frameworks for a solid foundation, skilled craftsman frame the necessary modules and services, some great trades wire and pipe everything together, and then a designer works to make it look and feel like home. At this point the projects are usually well scoped, and even if most projects feel agile, they’re still waterfall-ish in nature. The goal is still to have a house at the end of those iterations. What interests me is what comes after.

Technical debt is a concept that is often cited and often poorly understood. Many definitions try to oversimplify the meaning of technical debt, limiting to just a handful of causes. However the reality is technical debt accumulates even while doing nothing. Frameworks age and fall out of popularity, industry-standard techniques are replaced or refined, deficits in the original design are discovered, the list goes on. On top of general age and rot, poor communication and planning can leave systems tightly coupled, and not up to standards. Time pressure only adds to the list, including cutting corners, writing poor or limited documentation, and skipping testing. All of these in various capacities contribute to the accumulation of debt over time.

How do you combat this kind of entropic chaos? Some lesser experienced technical leaders might try to pay debt all at once, or even worse not at all. Some project leads call for extreme system decomposition into dozens of microservices. The idea is that each one can be independently rewritten over time, but this introduces a whole host of new engineering complexity. Some try to intersperse improvements as independent tasks, but then which debts get paid and which continue to acrue interest? The truth lies somewhere in the midst of all of these options.

Leaning back into the house analogy, I think there is some good concepts to borrow from the general contracting industry. There are two basic principles that I have seen good builders apply over the years: structure first, and bring things up to code. The first concept is easy – don’t invest in anything relating to finishing until the structure is sound. This means that foundational upgrades such as critical security issues, framework upgrades, and tooling changes should be addressed first. Otherwise any other debt or even improvement tasks that get completed are just begging to be redone. The second concept is driven from a regulatory perspective, but I think applies as well. When a contractor opens up a wall, they need to bring whatever is behind that wall up to code before the inspector signs off on the finished changes. As a result, the estimated cost of bringing things up to code is budgeted as part of the renovation itself. When dealing with a reasonably well built newer house, the renovation cost is likely going to be low. When renovating an ancient DIY house, the contractor is going to be pulling asbestos and lead out of the walls, so it gets planned for with a contingency.

No reasonable individual or contractor would spend thousands of dollars renovating a kitchen in a house with no roof, so why invest in a new jQuery-based theme when a project goal may be to migrate to React or Svelte? Similar to the concept of bringing things up to code, I feel the key to successful technical debt management is to be continuously tackling technical debt. Larger foundational items such as changes in frameworks, languages, and tools should be discussed as major projects, but upgrading and patching should part of a healthy development and maintenance lifecycle. When a service has some major rennovation going on, such as adding new features, the developer should take the time to bring things around that new feature up to code. Migrating from class components to functional components in React? Rarely will it make sense to do that migration all at once, but while a developer is already rewriting and redefining classes in a service? It makes sense to bring that up to code before shipping it off.

I’m not advocating for free-for-all rewrites, every developer for themselves. What I am saying is every feature, every major bug, should take the time to consider current best practices and team standards. If the team decides that classes are just fine and never decide to adopt functional components, that’s not debt, that’s a decision. But a developer going into a module finding a major defect like unsanitized inputs, or a straightforward performance improvement should be empowered to bring the code up to current standards, and document the debt that they paid while working on the original feature.

For me, a great feature of this is the code base is continually improving, no single developer feels burdened doing nothing but paying technical debt, and the cost is negligible. Chances are your developers are paying in some form for debt right now – either quietly making improvements, or being burdened with the need to work around debt, potentially incurring even more debt. When planning we typically ask for an estimate for the task, which often gets padded out quietly. Instead, explicitly build in a contingency for bringing things up to code. An additional advantage is over time, the effort for a task versus the debt paid during that task can be monitored. If the debt ratio is rising, it can be an early indicator that it may be time to look at structual or systemic issues.

In short, these house renovation analogies can fit the software lifecycle well. It offers developers a deeper level of ownership, and it offers an early warning system for uncontrolled debt growth. A software system, much like a house, needs regular and thorough maintenance on its components. Budgeting for these issues, and correcting them early, ensures that the code base remains in peak performance.

Did (A)I Write This?

This is the first in a series of posts where I will explore the interaction between human creativity and artificially intelligent algorithms. For this post I explored the use of GPT-3, a deep learning model that is capable of producing human-like text. I produced the prompt (in bold), and provided a human touch through editing, but overall the content in this article is artifically generated.

In the past few years, we have seen the rapid adoption of artificial intelligence into our daily lives. This has been driven by the development of powerful algorithms, but also by the availability of large datasets to train those algorithms. I believe throughout the next decade this technology will both revolutionize and threaten modern society. Already we are working in symbiosis with intelligent algorithms – from simple autocorrect to complex interactions with voice assistants. As this technology matures, our role will be continuously revised and redefined, in some cases disappearing entirely.

The question is not whether we will accept this change, but rather how we will react to it. I want to believe that the technology we create will be used for the benefit of humanity, but history tells a different story. We are a species that is more than willing to use our tools to cause harm to others. I want to believe that we will be able to control the technology we create, but history tells a different story. We are a species that is more than willing to use our tools to exert our will on others. The question is not whether we will accept this change, but rather how we will react to it. If we react by giving up, we will be left behind. If we react by working together, we will be able to shape the future.

Looking at the work above, it’s incredible to see think that this response was AI generated. With a rich enough initial prompt it is possible to generate large amounts of content, which can then be selectively edited into a cohesive narrative. It could become a powerful tool for generating novel concepts, combining concepts that are linguistically sensible, but perhaps different from typical human thought. This technology will only continue to improve and infiltrate more of our lives, let’s hope that the AI is right and we do work together to shape the future positively for humankind.

The Big Squeeze

We are living in one of the most prosperous times in history, empowered by fantastic tools, well thought out processes, and connectivity that civilization has never enjoyed previously through the Internet. Yet with all of this unprecedented wealth and productivity, society seems to be suffering. Poor paying jobs, effective inflation that is far outpacing income, and unaffordable housing.

The Rise of 5 To 9

Rather than tackle the underlying issue of the divergence of employee value versus compensation, an insidious alternative has appeared over the decade. The rise of the gig economy and side hustle as a means to patch over the compensation issue in our primary jobs is a corporate dream. Workers (and governments) aren’t pushing for fair wages, so many workers take on additional underpaid, high risk work just to make ends meet. The glorification of working culture in North America takes this to toxic levels: a sort of self-imposed 9-9-6 work life. Work your normal 9am to 5pm then go home and work a 5pm to 9pm job, likely also working on the weekends.

Nothing demonstrated this symptom of late-stage capitalism better than the latest commercial from Squarespace, which features a rewrite of Dolly Parton’s 9 To 5. The song is a critical look at the abuse that workers suffer under capitalism. It was then perversely rewritten as a “modern rallying cry for all the dreamers working to turn an after-hours passion or project into a career” and packaged as the solution to feeling underwhelmed and unfulfilled in your primary job. Rather than look at the lack of fulfillment and compensation as a symptoms of a sick system, it encourages to you continue to sacrifice yourself on the altar of capitalismin the name of self-fulfillment.

As the world continues to automate jobs, there will be a growing segment of the working population who will no longer have meaningful jobs. And it seems that the best capitalism has to offer is the opportunity to work soul-crushing bullshit jobs, jobs that provide little value for your employer, and provide little satisfaction for yourself.


Governments could work to correct the inequality in the current system by significantly increasing the minimum wage and indexing it to a realistic inflation portfolio. This would lift a significant number of people who rely on the gig economy to have an acceptable quality of life. The main issue here would be the gradually reducing number of jobs available in a post-automation society. It also continues to rely on individuals, who have a decreasing share of overall wealth, to fund social and societal obligations. Rather, it should be those that hold wealth such as property, and means of production who contribute a larger share into the society from which they reap their benefits.

I think that Universal Basic Income (UBI) is inevitable – people should not have to toil away on meainingless tasks for the right to survive, and we should be able to claim back our days for creative and personal pursuits. It would shift the tax curve to the right, allowing for a typical individual to enjoy a simple condition-free stipend with no tax implications. For those who choose to work, the tax curve would be steeper with the introduction of additional tax brackets. This would promote a healthy common baseline, while allowing individuals to still compete and produce value. It would greatly simplify government program administration as there would be limited need to review, amend, and approve programs.

🎵 Streaming Service Wars

tl;dr Apple Music suffers from only one problem: iTunes. YouTube Music feels half-baked at best.

Once in a while I like to review my subscription choices to see if I am still getting the most value out of each service. Most recently I started paying for YouTube Premium as a way to legitimately skip ands and access exclusive creator content. One perk of this subscription is the inclusion of YouTube music. I have been a happy Spotify subscriber for many years now, but glitchy application behaviour and some missing catalogue items made me second guess whether I am getting the most out of that subscription. I decided to revisit Apple Music and YouTube Music to evaluate their service quality.

Apple Music feels like a quite solid option, with one huge caveat: iTunes. I am a Windows user for my primary desktop and laptop at home and iTunes is an evil that I avoid whenever possible. The Apple experience has continued to decay into near unusability on Windows. I know they have the online player so you can avoid using iTunes, but I wish they would bundle this clean experience into a distinct Windows application. Much of the legacy library and device management that iTunes provided isn’t necessary for my day-to-day music experience. Despite the iTunes nightmare, the experience on my mobile devices such as my iPad and iPhone are excellent.

While there was no direct way to port my Spotify playlists to Apple Music, there was a free online service, Tune My Music, which allowed me to move my Spotify playlists and favourites smoothly to Apple Music. Given these services are all mature at this point I was a little disappointed that this migration process wasn’t native to Spotify, Apple Music, or YouTube Music. Despite the desired locked-in effect, it’d be much easier to poach me as a customer if I could easily take my music library with me.

Fresh off of this mixed Apple experience, I was hoping that Google would have produced something high quality with YouTube Music. They spent months advertising the service to me as an upgrade to Google Music (which I had used prior to Spotify), and a great value-ad to the general YouTube experience. Immediately I noticed how rushed this product felt. Like Apple, they have no native Windows application (or Mac application for that matter), and their mobile application feels like a lazy reskin of the the YouTube application. This set the tone for the entire experience I was about to endure.

While most content providers such as Tidal, Apple, and Spotify seem to have gone through the trouble to license large libraries of music with many record labels, it seems like YouTube has done the bare minimum required to be called a music service. It’s almost like they were sitting around the board room one day and someone said “hey, people upload music to YouTube, YouTube can make playlists, why not charge for this?” And then proceeded to receive a standing ovation. The quality of the experience is extremely variable. Some songs are from people who just happened to have uploaded the content, some is label-uploaded content via VEVO and others. Then I attempted to import my playlists.

While the experience using Tune My Music was good with Apple, YouTube Music was a nightmare. First since there is no sane user-level way to import, the tool integrates with the YouTube API directly, and promptly hits the 10,000 action limit as it attempts to match and write playlists via the API. My collection still is only about 3/4 imported, having to curate every re-run to get another chunk of my library imported. Then the fun starts – I would say a solid 10% of my library is unavailable on YouTube. Either people haven’t uploaded the music, or Google never bothered to sign detailed agreements with the various labels.

So, after my experience with Apple Music and YouTube Music, I can comfortably say that Spotify is still the reigning champ in my books. Cross-platform applications on Windows and Mac, decent mobile apps, integration with Sonos and most voice assistants. I’ll live with the odd quirks and bugs, at least I can experience them on every platform consistently and cleanly.