How is the idea for a product formed? A really cool idea is usually a jigsaw puzzle made up of many connective thoughts, and sometimes this process gets messy. My self-reflections that conceived RefactorKit are entangled with my learning journey of jobs-to-be-done theory, and evolved over many months, and are now transcribed across several blog posts.
For interested readers desiring linearity, I suggest starting from the origin story. Then, detour optionally into the ConsenseKit concept, which I analyzed using the jobs-to-be-done framework. This detour ends with the pivot from ConsenseKit to RefactorKit. Technical debt researchers could finish with reading the abstract which I created for a technical debt conference.
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:
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 🇨🇦
