026: SpringOne Platform Preview, Pokémon Go, will Azure win against AWS? (Pivotal Conversations)

Continue reading “026: SpringOne Platform Preview, Pokémon Go, will Azure win against AWS? (Pivotal Conversations)”

Highlight from: The Small Batches Principle – ACM Queue

Small systems are more flexible and malleable; therefore, experiments are easier. Some experiments would work well, others wouldn’t. Because they would keep things small and flexible, however, it would be easy to throw away the mistakes. This would enable the team to pivot, meaning they could change direction based on recent results. It is better to pivot early in the development process than to realize well into it that you’ve built something nobody likes.

Google calls this “launch early and often.” Launch as early as possible even if that means leaving out most of the features and launching to only a few select users. What you learn from the early launches informs the decisions later on and produces a better service in the end.

More…

From: The Small Batches Principle – ACM Queue

The concept of activating the failover procedure on a system that was working perfectly may seem odd, but it is better to discover bugs and other problems in a controlled situation than during an emergency.

This is a shift in cloud native thinking: accepting that there are errors in production and forcing those errors to happen so you can fix them. It’s like avoiding that psychological trap we all get into: if we don’t acknowledge a problem it must not exist and fixes the problem. Computers don’t act that way – you can’t bury a problem – and humans don’t either, really. So, just force the issue, but in small, controlled batches to limit the blast range. Better you control it than something else making the negative effect larger and worse, most likely.

Source: The Small Batches Principle – ACM Queue

Highlight from: Why Continuous Delivery and DevOps are Product Managers’ Best Friends – MindTheProduct

I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:

“We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.”

More…