At MenderCon, we want to celebrate the software maintainers of the world and create a community where we can all learn from each other. Building on the organic community that's emerged from the podcast Legacy Code Rocks! this virtual event is a chance for menders all over the world to come together and talk about what makes improving software interesting and fun.
Our work with legacy code doesn’t often put us in a position to move quickly into new or trendy tooling. And while we almost always introduce Docker very early in our projects, it is usually only for the purpose of standardizing and easing setup of developer environments. Transitioning a live environment to containers, however, can be a daunting prospect, especially for monolith applications. But, the payoffs can be huge.
As a company that specializes in working with legacy code, we’ve run into our fair share of technical debt over the years. Many teams have deferred their maintenance for so long that any tiny change to the code takes forever to get out the door. But there are other things that contribute to technical debt that you won’t find in the codebase.
One of the things that I always forget to do when I set up a new computer is to install all of the special fonts that we use at Corgibytes. In the past, I've found the process to be tedious and time consuming. But recently, I've found a really nice way to install fonts from the command line if you're using macOS.
During a recent Legacy Code Rocks virtual meetup, a community member shared that a senior colleague had recently rejected a request to change a variable name. I used to encounter resistance to refactoring all the time, but since starting Corgibytes, I don’t come across it as often. But I’m curious if there are others out there who have encountered this sentiment, and I’m especially curious about how they’ve dealt with it.
I often encounter software projects that have absolutely no automated tests. This is rarely because the development team feels that authoring tests is a waste of their time. It’s most often the case that the team would love to have automated tests. If you feel like your project or team is stuck when it comes to automated testing, then I’d like to provide some guidance and specific techniques for how to get started.
Software systems can find themselves in a state of "rock bottom." When we encounter projects like these, we need to channel our inner monk. Start where you are. Eliminate the shame that goes with having a messy codebase. Embrace that your system is worth investing in and start making it better from where you are today.
About one year ago, on Monday, November 19, 2018, I said goodbye to my dog Ein. Ein was my Corgi and the original inspiration for naming my company Corgibytes. I want to take a few minutes to tell you about Ein, what she was like as a dog, how she touched my life, and how sorely she’ll be missed.
Occasionally, software developers get involved in discussions about what a good goal for code coverage is. What's the right answer? Well, clearly it's 100%. After all, why wouldn't you want to have all of your codebase covered by automated tests?
What if you could prove to your team that one of your commits didn’t change any behavior? And by any, I mean any. It doesn’t add a new feature; it doesn’t fix a bug. It’s nearly impossible that any behavior is altered by the commit. If you could do that, how would it affect the way your team operates?