@d_stepanovic@mastodon.social avatar

d_stepanovic

@d_stepanovic@mastodon.social

Trying hard not to think about small batches, bottlenecks, and systems. In the meantime: XP, Theory of Constraints, Lean, Systems Thinking

This profile is from a federated server and may be incomplete. Browse more on the original instance.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

One of the big benefits of slicing, that I don't get to hear at all, is that the way we sequence slices by value, as a byproduct also serves as a guide on where are the fracture planes or seams for gracefully degrading business capabilities when things go south in production.

The same lines of slicing can often be used to shed the less important load to protect the more important parts of the business.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

It's an order of magnitude easier to do the Gemba Walk when teams co-create (and reduce Work in Process as a result of that) than when every individual in the team is running in their own isolated direction.

That means way easier to observe team dynamics (and more reliable signal), the work being done, and impediments to flow.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

I'm looking for ads/tracking blocking for the traffic going through the home wifi.
Are there any other recommendations besides nextdns and adguard?

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

From the “right leverage point, wrong direction” series (reference to Jay Forrester), the majority of teams I worked with when faced with high batch transaction cost relative to batch size, instead of reducing the transaction cost they increase the batch size.

d_stepanovic,
@d_stepanovic@mastodon.social avatar

Some examples:
— conflated design, leading to having to rely on coarser grained, integration tests ⇒ run tests only after a bigger change and take longer time to figure out when something breaks
— lack of availability of a dependent team ⇒ Big, Speculative Design Upfront and premature negotiation of contract
— deployment pipeline taking long relative to the size of the change ⇒ increase size of the change deployed, increasing the risk of an outage

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

Let's put it this way.

Find me a software development philosophy as coherent as XP, that yields tighter feedback loops and more joy, and I'll gladly be the first one to promote it.

I'll be right here waiting for you.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

Though not a fan of estimates (to say the least), for the teams that use them, the idea of the estimates is not to put the pressure on the team but to put pressure on the slicing.

Teams that do the former often end up both with lower quality and delay in time to value (not to mention burn out and lower morale).

It feels hard to find different slicing options in the start if the slicing muscle is weak, but as you exercise it often, it becomes easier and easier.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

Whenever we experience a problem in production, the usual intervention I observe is introducing more gates on the way to production.
Typical examples are: additional reviews and approvals, isolating work on the branch and for a longer time, deploying to a separate dev/QA/staging environments, adding more integration and e2e tests, etc.

1/n

d_stepanovic,
@d_stepanovic@mastodon.social avatar

As Jay Forrester would say, good intervention point in the system, but wrong direction.
Counterintuitively, as a result, you make things even worse.
Or, in other words, systems often deteriorate not in spite of our efforts to improve them, but because of them.

2/n

d_stepanovic,
@d_stepanovic@mastodon.social avatar

When you introduce more stages, it takes longer to reach the production, which signals higher batch transaction cost, which drives average batch size up, which drives risk up exponentially along with delaying feedback. In the end, you end up with more risk and more rework.

You need faster, not slower way to reach the production. That makes the relative cost of releasing smaller changes less expensive, which allows you to validate assumptions sooner and reduce the risk along the way.

3/n

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

Pushing straight to trunk development.

That's the only thing I mean by trunk based development.

No (official) branches. Just a stream of tiny commits landing on the trunk, from multiple times per minute to every few minutes.

d_stepanovic,
@d_stepanovic@mastodon.social avatar

@ratkins something happened in the last two decades apparently

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

There's a lot of "you can do PRs, have branches, do async code reviews and still achieve continuous integration" out there.

Sure.

Also find me a team that is doing these and where oldest commit on every PR lands on the main in under a day (CI) and I'll find you a unicorn.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

I need a drawing pad/tablet for sketching during Zoom calls or drawing diagrams.

Any recommendations (besides iPad)?

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

If you need to take time to understand the code before you start refactoring, the refactoring step you plan to do is probably already too big.

The understanding of the code is built as we refactor to the same extent that we refactor as we get a better understanding of the code and domain.

Limiting time for ourselves to understand a piece of code can act as an enabling constraint for finding a smaller refactoring step we could make.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

A regular reminder that in a fully loaded system of work (and the one where people mostly work individually is one of those) lack of availability causes lack of responsiveness, which leads to delays, which leads to work items spending most of their lead time waiting for someone.

In short, wait time dominates lead time.

Trying to estimate (effort) in these cases is a poor man’s attempt at achieving predictability in a system with inherently low predictability caused by the way of working.

qcoding, to random
@qcoding@iosdev.space avatar

In a r/SoftwareEngineering thread on "#UnitTesting is a generalized approach not an ideal solution for all systems" I touch on why #XP and #TDD haven't taken over.

My rebuttal boils down to this: Does the lack of XP among businesses really mean it's less effective? Or are there other reasons it hasn't spread?

Here's the middle of the thread where it gets really interesting: https://www.reddit.com/r/SoftwareEngineering/comments/165dv8k/comment/k1o6mfj/?utm_source=share&utm_medium=web2x&context=3

d_stepanovic, (edited )
@d_stepanovic@mastodon.social avatar

@jitterted @qcoding

the fact that most companies don't do XP says nothing about how effective it is.
in order to stay in business, you just need to be better than the competition when it comes to engineering culture and practices.
and we'll agree that the median competition is terribly bad :)

people confuse not yet reaching a threshold for an absence of a threshold (#SystemsThinking).

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

High WIP can be a perverse way of making that one person that most of the people in the team will depend on very important.

Examples: ivory tower tech lead, product manager, engineering manager, etc.

The fewer things in progress, the less wait time for these people, and the less inflated feeling of self-importance.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

A T-shirt that says “Jirassic Park” would explain so many things.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

If you refer to the build server as a CI, I can pretty much guess you're also not doing the CI I'm thinking of.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

You don't need more speculative design (overengineering), you need faster feedback loops.

I've seen too many developers trying to address slow feedback loops with more speculative design. Also known as “let's do it properly this time!”.

The link between these two is that longer feedback loops drive a higher cost of change, which incentivizes us to speculate upfront more and increase the batch size.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

https://shoulditestprivatemethods.com/

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

In huge majority of cases you're way better off without a DI/IoC container and their magic and injecting dependencies on your own (pure DI) instead.

Heresy, I know.

But magic hides compilation feedback when wrong dependency is provided or it's not provided at all.

It also reduce the pain of having too many dependencies of a class or pain of adding "just one more".

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

Dependencies are most often not the problem per se. Dependency on a team that has lack of availability tends to be.

If a team B that a team A is dependent on was available whenever needed it wouldn't be as much of a problem.

A traditional way of trying to solve the lack of availability by planning more doesn't solve the problem because the real amount of needed slack in the system is almost always underappreciated.

d_stepanovic, to random
@d_stepanovic@mastodon.social avatar

I like the definition of psychological safety from Timothy Clark, being “an environment of rewarded vulnerability”.

If we're working in an environment where we're not even able to exercise vulnerability, let alone be rewarded for it, then we also don't have psychological safety.

1/3

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • mdbf
  • ngwrru68w68
  • tester
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • DreamBathrooms
  • megavids
  • tacticalgear
  • osvaldo12
  • normalnudes
  • cubers
  • cisconetworking
  • everett
  • GTA5RPClips
  • ethstaker
  • Leos
  • provamag3
  • anitta
  • modclub
  • lostlight
  • All magazines
    •