Presentation: Succession: A Refactoring Story

At GitHub, we have a GraphQL and a REST API. I focus on the REST API (we have about 550 public API endpoints in the REST API and that keeps growing). Most of my team works on the GraphQL side of things. I mainly work on the guts of the API - the plumbing, performance, and consistency. Much of my work is around things like code reviews and making sure that we don't break backward compatibility (even when we wish we could).

Most of GitHub is running on Ruby on Rails. The entire API is a Sinatra app that's mounted inside of rails. It's probably 8 or 9 years old at this point. The newer code at GitHub includes Haskell, Go, and Python. We probably have some Java in the data science side of things. We also run a ton of JavaScript with Electron and Atom.

A few years ago, I started an open source project that gives people little exercises to do. One of the exercises was the 99 bottles of beer song.

For such a simple nursery rhyme, it has some surprising algorithmic complexity. Everyone was trying to tackle the design in a way to make it simpler, but everything just made it worse. I didn’t even know if there is a good solution until a friend of mine came up with something that was pretty elegant. We started working together on it. I would do the factorings to try to get from a basic simple design to one of her designs. From that experience, we eventually developed a refactoring and object-oriented design course. We then went on to co-write a book about refactoring and object-oriented design.

Another motivation was my observation that people do very odd things in the name of refactoring, and it doesn't always turn out well. When everything breaks, instead of backing out and trying something smaller or something different, they'll keep going down that path. Hours or days later everything is still broken, and they often end up having to throw it all away. Even if it does manage to work,  you have 60 or 70 commits and now you don't know which of all those changes mattered. I've focused pretty hard on techniques for thinking smaller and finding paths where you can keep your tests green in a more controlled rigorous manner.

Anyone who has hands on keyboard writing code. It could be frontend, or it could be backend, It really doesn't matter what language you're working in. The day-to-day techniques of how you might avoid making something fail will be different in different languages, but the basic philosophy of thinking in smaller steps is the same in all the languages I’ve worked in.

A lot of them are so small that they're not worth naming. They're very tiny meticulous steps. But there are techniques along the way. One of the ideas that I talk about is the idea of shameless green (which Kent Beck mentions in Test Driven Development). He says get to green as quickly as you can, and then from there, getting to great. Don't be clever, don't be smart, write the stupid solution. When everything is working you can get clever, even though often you don’t need complex, clever code. Interestingly enough, sometimes we feel embarrassed by simple code when we shouldn’t.