Much like running up bills on your credit card, technical debt can easily get out of hand. To avoid this happening, you need to keep track of how much debt you’re building up.
Technical debt metrics are designed to help you make sense of all the data you collect. There are many different metrics to choose from nowadays, and plenty of tools for recording the data.
Dear editor, I would like to suspend publishing this my article for 3 weeks as it has a dependency on my article on another resource. Thank you for the understanding.
How do we know when a user story is « done? » Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.
Organizations are continuously looking for ways to track, measure, and evaluate developer workflows. Done effectively, this creates the means to improve performance and code quality, reduce time to market and increase profits. But it’s not always easy to measure efficiency. What may first appear to be evidence of a team’s hard work may be an indication of the bigger challenges and inefficiencies of code churn.
Code churn is a measure or indication of how often a file changes. It typically refers to how often a developer throws out code (such as a function, file, or class) within the first 2-3 weeks of writing.
If you’ve read our piece about the habits engineers need to beat tech debt, you might recall Conway’s law, which states that organizations which design systems […] are constrained to produce designs that are copies of the communication structures of these organizations.
It’s one of the forces that can push us towards technical bankruptcy because the systems designed by software engineers are constrained by their company’s organizational structure, over which they have little control. The right way to fight these forces is to talk about tech debt across the whole company so that everyone can understand why it’s vital to manage it carefully.
What happens when you put two top thinkers together to talk about DevOps, continuous integration, and CI test automation strategy?
That’s what happened in November 2019, when Dr. Nicole Forsgren, VP of Research & Strategy at GitHub, and co-author of Accelerate: The Science of Lean Software and DevOps, joined a webinar with Angie Jones, test automation consultant and automation architect at Applitools.
Last week, a few of my very senior colleagues and I were remarking about how many new DevOps tools are emerging and how it’s getting harder and harder every day to keep track of them and where they fit into the world. I asked several of them where these tools — Ansible, Terraform, Salt, Chef, Bamboo, CloudFormation — fit in. Why would I use one versus the other? Are they even the same thing? Am I missing a major player? I got back the same blank stares/questions that I had. So, I thought I would do some research, read, and try to make sense of it for all of us so we could classify products into categories or uses to which we are all familiar.
Before we start to talk about DevOps tools and categories, let’s take a step back and discuss a few basic (but often overloaded) terms and what they mean.
Today, we’ll talk about design patterns and some of the best online courses to learn design patterns in Java. If you are wondering what a design pattern is and why Java developers should learn them, then let me give you a brief overview.
In simple terms, design patterns are nothing but a tried-and-tested solution to common programming problems, for example, the creational design patterns deal with the problems of object creation.
I’ve been practicing Agile methodologies for some time now. The most common ceremony that I’ve seen Agile teams do is stand-up also known as daily Scrum meeting.
I’ll not go into what a stand up or daily Scrum is and the value it brings. I appreciate the value it brings and would encourage teams to follow this ceremony religiously.
