Slow tests can help you deliver value sooner

Test execution time can tell you a lot about design of your service. If you have a bunch of domain logic in the parts of the service where it shouldn’t be (controllers, repositories, external gateways or any adapter of that sort), your tests have to spin up a mock MVC or embedded database or stub service in order to test it. The more logic you have in these parts of the app, the more tests you’ll have against them, the slower the test suite.

»
Author's profile picture Dragan Stepanović

Cut the batch size instead of increasing WIP

When faced with pressure, teams should cut the batch size instead of pulling in more stuff and increasing WIP (as it’s almost always the case).

»
Author's profile picture Dragan Stepanović

Most of the time is spent waiting in queues, not processing

»
Author's profile picture Dragan Stepanović

Having problems with system reliability?

Try with more aggressive timeouts, use circuit breakers and bulkheads.

»
Author's profile picture Dragan Stepanović

Build quality in by reducing inventory

Reducing inventory accelerates the feedback, so THE way to build quality in is to reduce the inventory and thus shorten the feedback loop.

»
Author's profile picture Dragan Stepanović

High demand and low predictability incentivizes the system for big batches

Same scene in Berlin U-Bahn (metro) this morning.

»
Author's profile picture Dragan Stepanović

Your sense of relief is indication of a too long feedback loop

In systems with very short feedback loops there are almost no events. Everything seems to be boring. The longer the feedback loop, the more pressure builds up with time elapsed, the greater the sense of relief and achievement this produces on emotional level when the feedback loop is closed (marking an event that has just happened in the system). Ironically enough, watching for moments of relief and achievement says a lot about existence of events that are too big, which in turn reflects the existence of too long feedback loops.

»
Author's profile picture Dragan Stepanović

Enabling constraint for incremental development

Committing code very often and deploying to production with every commit is enabling constraint for getting better at incremental development, one of the most overlooked skills in software development.

»
Author's profile picture Dragan Stepanović

3 powerful questions when discussing a solution

Three very powerful questions to keep in mind when discussing a solution:

»
Author's profile picture Dragan Stepanović

Organizations with a lack of psychological safety are incentivized for big batches

Let me unwrap that.

»
Author's profile picture Dragan Stepanović

Bounded information space and local optimizations

Actually, problem with silos is that by removing broader context in which they operate, people tend to locally optimize, which almost never produces overall outcomes that we initially wanted to achieve.

»
Author's profile picture Dragan Stepanović

Pain with Feature Flags as a feedback tool

In case you’re doing Trunk Based Development (and you should be doing it) you already know or have heard that Feature Flags are a form of technical debt. In fact, some teams have so many difficulties with this introduced technical debt that they “lose trust” in Trunk Based Development and fallback to Feature Branching. The important thing here to realize is that this is actually a decisive point in the development.

»
Author's profile picture Dragan Stepanović

Minimizing Consistency Boundary with Event Sourcing

Imagine you have a system for managing customer subscriptions of your SaaS product. Your customer can be a company and can have multiple licenses he can use with the subscription he payed for. Customer also wants to be able to assign and unassign those licenses to his employees. Also, customer wants to be able to see how many unused licenses are available for a given subscription and how many licenses in total are used (across different subscriptions that he has payed for).

»
Author's profile picture Dragan Stepanović