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.


Posts tagged “refactorkit

Training for Technical Leadership

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.


The Jobs-to-be-done when communicating software refactors

The ConsenseKit case study

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).


How ConsenseKit became 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.


RefactorKit - The Origin Story

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.


RefactorKit - Abstract

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.


ConsenseKit - build consensus for hard tech decisions

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:

  1. deciding to refactor
  2. deciding to pay down “technical debt” and
  3. deciding to invest in reducing software complexity.