Why We Changed a Core Value
We recently changed one of our core values to remove an obviously gendered term. This is an exploration of what prompted us to do so.
We recently changed one of our core values to remove an obviously gendered term. This is an exploration of what prompted us to do so.
I’ve had the idea for a new testing tool in the back of my head for years. I’ve been calling it Cukeness (more on that name later). I was actually working on the project when I first asked Andrea to join me on the Corgibytes journey. I did a horrible job of explaining to her why it needed to exist. So she said that I should put it on pause and focus on other things instead.
This wasn't the sexiest project we've ever worked on, but a combination of good tooling, careful preparation, and a fair amount of mind-melting compiler error resolution made this a one of our best remodeling efforts of 2018.
A little while back, I arrived at my desk to a message no one likes to receive: the production instance of a client's primary app was down. What's more, the site had just gone live earlier that week, and thousands of users were trying to login.
If you want to eliminate your technical debt, communication HAS to be a critical component of your efforts. If you're struggling to break up your monolith and move to a microservices model, the first place to look is how your team is communicating. Command and control silos will result in monoliths. Self-organizing and autonomous teams give rise to microservices.
We frequently work on projects where it's best to start out with an older version of ruby. Getting these to install correctly feels like a dark art sometimes. Here's a quick series of steps that we had to follow to get Ruby 1.8.7 using RubyGems 1.8.30 installed via RVM.
From what I see, it's this relentless commitment to maintenance and modernization that enabled American entrepreneurs like Carnegie to outpace their British competitors, and it's a lesson that modern companies would do well to learn, lest their competition overtakes them.
In many ways the Ship of Theseus paradox is quite similar to software development. Is this app the same one it was five years ago? How about two? What about after the massive refactor we *just* finished? If it still serves the same business users in the same capacity, but we rewrote it, does it matter?
Your software isn't working the way you'd like. What should you do? Scrap everything and start over or slowly transform your application into something more in line with your vision. In this post, we explore the differences, strengths, and risks of each approach.
Software is one big party! The question is: When's the optimal time to pause the partying so that you can restock and clean up? Well, it depends on who you ask.