A Tale of Two Feature Flags
I spoke at RubyConf last fall about feature flags and tech debt. Here’s the abstract:
It was the best of times, it was the worst of times. Feature flags are a quick win for development teams seeking a way to more rapidly release software but can create unexpected technical complexity. Join us for a comparison of the life-cycles of two seemingly similar feature flags. We’ll discuss the challenges teams often face when implementing them, as well as strategies to avoid these issues and deliver software quickly and reliably.
If that sounds interesting, you can watch the talk here.
Designing Project Onboarding
I’ve been thinking a lot about project onboarding lately.
A few weeks ago I started working on a project with an existing code base. On my first day I was able to pair-program on a bug with another developer. My pair was generous enough to use our time together to walk me through the process of setting up my workstation. We ran Puppet on my machine. He showed me a Gradle task to build the code. When it came time to run our tests, he knew all the command-line aliases to do so.
Two days later I swapped pairs to work on a feature. My new pair’s workflow referenced completely different build commands and git convenience scripts.
The Hundred Pushup Challenge
When the ThoughtWorks Quito office first opened I organized a monthlong immersion for our first ten new hires. We were so small that the entire office would work through training materials during the day and head out to dinner afterwards.
After that month, as project work started and we hired more people, I noticed that there was a high amount of interaction within project teams but that communication across the office was infrequent. Project teams went to lunch at the same time; after-hours events were attended by groups from the same project. I was pleased that individual project teams were forming and wanted to ensure that the office was doing the same.