The pandemic has taught us so much. Including a better metaphor than “technical debt”. Even after researching a lot about architectural tech debt (ATD), I’m not confident I could explain it to you. Perhaps making matters worse, the term inherits the definition of “tech debt”, which itself is a loaded phrase that is missing a universally accepted definition in the tech world. They say teaching a subject is a good way to learn it, so this is my attempt at explaining ATD.
I was invited to a tech employer engagement event at Humber College, North Campus in Toronto. In the post-grad information technology program there, students participate in a collaborative group project with the tech industry known as a “capstone project”. This end-of-year project is an opportunity for students to get valuable industry experience by working on a real project for 10-weeks, and for employers to connect with local talent.
I found a discussion on the role of a “principal engineer” on Hacker news here. The article and HN comments are a unique insight into this role. This discovery had surfaced as I was researching the concept of RefactorKit, and it made me think - what role can RefactorKit have in training technical leadership? Here are some curated comments.
In the month of February 2019, I had some time between projects which I occupied with research into the art of product development. There seemed to be a group of people on my Twitter feed which specialized in something called “product”. I didn’t know what it meant, but one guy made it sound so easy to define what product to build. That’s how I found out about jobs to be done. Here’s what I learned about it, and how I applied this product definition technique to the concept that was then called ConsenseKit (which later was renamed to RefactorKit).
The more that I think about it, the more I believe that I’ve made a mistake in the product definition process for ConsenseKit. The practice of JTBD and ODI teaches that everything stems from the Core job to be done. It is a foundational concept that forms the basis for the job map, desired outcomes and more. Here’s what I learned, and why ConsenseKit is now RefactorKit.
This article by Michael Williams on software system dynamics struck a nerve with me. I realized that in the past I too experienced situations where refactoring decisions were very difficult to make. Williams’s perspective on using system dynamics to communicate refactoring decisions lingered with me for a few months after, and would persist. This is the story of how RefactorKit was born.
I had written this abstract for Dr. Antonio Martini before we were supposed to meet up at TechDebtConf 2019 in Montreal. I unfortunately could not attend the conference, but I had sent this to Dr. Martini via email. Here is the original abstract of the RefactorKit concept.
As a software engineer, your job is hard enough. Solving technical problems and implementing efficient solutions is just part of the daily struggle. Every once in a while, though, the decisions you make have the potential to dramatically impact the business that pays your bills. I’m talking about:
I’m keeping these links safe, but not secret. These resources are freely available to download and have permissive licensing to use in your projects. I want to re-share these as much as I can, but I also need a place where I won’t lose them over time. Up on the blog they go!
One of the main reasons that people hire me is to code. The reason that I say that is because I am using the language of the “jobs-to-be-done” or JTBD theory of how to understand problems and solutions/services.
I was happy to be able to put my Gear VR back in action; I haven’t used it much since doing some testing and prototyping for projects at Sovilon Studios. I’ve watched soccer games in VR a couple years back, but the experience is now much more appealing and indeed special. So what’s it like?
Every real estate agent can tell you this. Booking showings is part of their job that sucks and gets in the way of a seamless experience for their clients. This is because it is a coordination challenge that involves a large group of people who sometimes have differing motives and lack reasons to coordinate. This problem has affected the industry for many years, and is difficult to solve. But today, we will try.
The Sovilon logo, wordmark and all symbols, icons, animations and content are Copyright © Sovilon Software Inc 2018-2024. All rights reserved.
Proudly made in Canada 🇨🇦
