![]() ![]() What used to be our hardest issue to tackle is now one of our most celebrated processes that everyone can rally behind thanks to Code Climate. Each time the Web team's GPA gets close to the Ops team's GPA, the Ops team does some mob refactoring and raises the bar. Gamification of this process has also occurred as our Web team has created a healthy rivalry with our Ops team's Code Climate score. Since following this new rule, our web application's Code Climate GPA has risen from 1.62 to 2.38 in the past 9 months, which is significant considering we have close to 1,000 classes, controllers and modules in our app. We let Code Climate scores speak for themselves. No one has to be the bad cop that subjectively judges every commit. Since Code Climate can analyze any branch on your repository and notifies you of quality changes, it can objectively enforce our rule through detecting code duplication, high churn, or too much complexity. Important enough of a cause for everyone to rally behind. The most diligent developer placed on a team that just doesn’t care will find it difficult to maintain the enthusiasm needed to fix niggling problems.ĭuring one of our sprint retrospectives, we were discussing what processes we could implement to resolve this issue and someone said: 'what if we made a rule that every time you push code, you have to improve the overall quality of the code base'. There was nothing in place in terms of engineering processes that enabled us to address this issue as a team in a sustainable way. This worked to some extent, but only some engineers took it seriously and our Code Climate score would fluctuate up and down depending on how fast we had to move with our projects. We would refactor and abstract common logic and would rely on Code Climate to quantify our TD efforts. We believe in the saying you can't improve what you don't measure so at first, we used Code Climate to provide a starting point for our TD battle. This is when we discovered Code Climate.Ĭode Climate provides an objective analysis of the quality of your code and gives you the information and tools you need to fix it. We needed a process that would prevent us from introducing new TD while aiding us in our efforts to correct a lot of the existing TD in our application. We tried to do 'TD Week' where the entire engineering team spent a week paying down the debt, but you can only make so much of a dent in one week. We tried to carve out time in our backlog, but it was hard to prioritize it over bugs or product development. For us, that issue was technical debt (TD). As a result, our bug backlog has never been smaller.Įvery once in a while, we come across an issue that we struggle to address. For example, when we came to the conclusion that we were introducing too many bugs, we implemented a more rigorous code review process with GitHub pull requests. ![]() Like most engineering teams, we know we're not perfect so we're constantly refining our processes, which tend to be driven by the services we use. The apps and services an engineering team chooses to use directly influences the processes and culture of the engineering team.Įngineering teams put processes into place to create an environment that cultivates productivity, prioritized efforts and efficient communication. The apps and services I use and the way I use them directly influences how I work and what I care about as a professional. Services like Evernote, Postbox, and Asana keep me organized and working on the highest priority tasks. There are two things I'm always looking to improve: how productive I am and how prioritized my efforts are.Īpps like Alfred, BetterSnapTool and Vitamin-R help me to work faster and stay focused longer. I'm passionate about finding ways to improve my daily workflow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |