RefactorKit - The Origin Story

1 minute read Updated: September 21, 2019

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.

At some point, I created SoftwareSystemDynamics.com, hoping to turn my interest into a side-project to complement Sovilon Studios core offering of software development services.  I went through several naming and branding iterations. I called the first SimuSnap, and then became enamored with the name FactorSnap, which was a “snapshot of the factors” that affected development teams.

I thought of this, at the time, as a communication problem. I started defining the product, even going so far as to mockup logos for FactorSnap, without really understanding the problem at hand. I tended to get excited about new products. Sure, there was a need for better communication tools, but this was only part of the process of actually making refactoring decisions.

Williams renamed the title of his article to include the word “refactoring”. The positioning was clearly oriented towards convincing business stakeholders. I found more articles online about refactoring, and some themes were common to them. My confidence about being able to provide a generalized solution increased, as it seemed like there was enough in common for a tool that could really help development teams.

That’s when I started more rigorous research. I discovered the work of Dr. Antonio Martini et al., and his literature about architectural tech debt. The art of refactoring seemed to be a complex, cross-disciplinary skill, utilizing decision theory, risk porfolio management, stakeholder management and systems theory. The applications for such a “tool” spanned across all types of software, across companies, and across industries.

If there was a well-defined process for helping software teams make better refactoring decisions, it could be a million dollar idea.


This is how RefactorKit was born