quality

Hope creep is the plague of value delivery. We assume that since something worked in the past it will work again.

Code coverage is the measure of the amount of code being executed by tests. It’s an easy number to measure and a minimum value is frequently set as a goal.

I’ve been a software engineer for a while. When I had the opportunity several years ago to help uncover the core practices needed for continuous delivery, one of the things we needed to know was how to measure the outcomes.

If you don’t follow Dave Farley, co-author of Continuous Delivery, you’re missing out. In a recent conversation about the challenges of refactoring legacy code, one of the responses talked about when to resolve tech debt.

I recently saw a documentary on the history of the Ford Edsel. There were so many lessons on the UX research, design, manufacturing, and marketing of Ford’s new brand that apply to developing any product.

In the lifecycle of most applications there comes a time when they will go into maintenance mode where changes become very infrequent.

“We want our teams to be more efficient and deliver higher quality!” “We sure do, how will we measure it?

Has this ever happened to you or have you ever seen a support request like this? “We’re trying to deploy a K8S cluster to our server, but it can’t reach our vLAN network.

Protecting the Business Developer driven software testing is not new. Studies show that high performing organizations depend on tests written by developers instead of handing off to external teams of “Test Automators”.