Is Environment Maintenance a Detriment to Product Delivery?
"We need to build more stuff, faster." Does that sound familiar? With today's technology along with DevOps and continuous delivery all over tech headlines, it is no wonder that our organizations are fixated on just going faster.
A challenge I encounter with a large number of organizations is, in their rush to build more, faster, they spend more time on environment maintenance and less time on actual product learning and validation.
A Brief History of Time
How did we get here? Twenty years—even ten years—ago, standing up servers, databases, and networks was costly. Expensive in time, hardware, possibly even licenses. To create new environments was a project. Like most projects, once money is spent, it will be maintained. We then introduced more problems: Our release cycle introduced defects into the wild ... so we created another environment to test patches separate from the environment for new code. Special project? Better get a different environment.
The data challenge compounds this problem. We were designing systems that weren't testable, and our testing practices were manual. When systems aren't easily testable, we spend an enormous amount of time trying to “find the data.” We then guess if the data was valid, the environment was unstable, or the product was weak.
We guessed and stumbled and branched and built environments.
Here We Are
And so our environments grew without second thought. That leads us to today, when most organizations are supporting a multitude of environments. We spend time trying to get the right data in the right environment, managing connectivity and ripple effects. We push product through environments. We want to go faster, and our environment is a ball of mud. Automating mud is a bad idea.
What Can We Do about This?
To address this challenge, we need to reflect on the assumptions that led us here. Environments, data, connectivity—all no longer need to be static and managed. We need to rethink. We need to:
- Focus on product learning. Pushing product through environments is a bold assumption; it is product arrogance. Pulling product through tests changes the way we think. By focusing on the product (the outcome) first, we are already moving away from focusing on the outputs (the environment).
- Make systems testable before you worry about testing. How long does it take to get your product into a consistent state for testing? Can you test at various points in the system by creating a state or is each product test a full pass? Not being able to create a repeatable state not only affect testability, it affects time to demo new ideas and how quickly we can learn.
- Understand stories and acceptance criteria might not be enough. We need to understand how our product is going to be used. We need better discussions and better examples.
There isn't one solution to rule them all. What works best for someone else worked well for their context, but your challenges are most likely different. Instead of rushing into DevOps and continuous delivery through automation and virtualization, start by rethinking your approaches to your environments and testing.
Join Joel at STAREAST 2015 to explore removing environment thinking as a constraint to product delivery and learning.
