Self-Reinforcing Software Quality Training

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 proposed to several teams the RefactorKit concept and was well received. It’s interesting that the RefactorKit project itself is about helping software development teams make better code health decisions.

Self-Reinforcing Feedback Loops

There is an interesting circular nature about this situation that I’d like to disect here. Humber students will be writing code for RefactorKit, a concept that helps software teams make better decisions when writing code. Ideally, the students and myself as project coordinator would be able to use RefactorKit in order to help build RefactorKit. After all, we will be building software and will need to rationally decide whether to pursue refactoring efforts with limited time and resources - like real software teams do.

In addition, the expectations for code quality present an interesting experiment opportunity. These are students, some with a lot of experience but also still learning, so expectations should be set accordingly. This is not to judge or critique them, but simply to point out that varying levels of code quality are expected in any real-world codebase. If all programmers were perfect, we wouldn’t need to refactor code at all. But the real world is imperfect, and all teams have to hire and train new people eventually. I fully expect, during the course of the project, to make several key refactoring decisions because of this expected code quality diversity. And this is not a bad thing! It will present the opportunity to make real refactoring decisions.

Theres only one problem…

RefactorKit is just a concept right now. In order to activate the kind of self-reinforcing feedback loop I’m describing, RefactorKit first needs to exist. Right now, it just exists in my head, on this blog and the pages in my notebook. It seems to me there is a set of minimum features needed to activate this feedback loop, and I’ll have to think hard about what that is.

I met with quite a few awesome teams there, but there were many more that I simply wasn’t able to meet. The students generously give their time for the duration of the project. I would take my role quite seriously, and hope to give them the real-world experience they’re looking for. Upon completion, they should be better programmers and know a ton about code quality and the kind of culture that promotes a healthy, happy development team.

If you’d like to read more about RefactorKit, visit the blog page or RefactorKit.com

To try a super early non-functional pre-alpha that I built in a day, go to https://app.refactorkit.com