Blog reading

I'm trying out a plan to be more deliberate in technical reading, especially with tech blogs.  The plan is to set aside time to read blogs, taking notes and summarising what I read.  These are really only intended for my own use, and the aim of posting them here is to make it easy to refer back to things.

https://www.mountaingoatsoftware.com/blog/an-agile-team-shouldnt-finish-everything-every-iteration

Teams should aim to finish all the sprint work 80% of the time.  Aiming to finish everything every time leads to undercommitting and safety margins, especially if failing threatens consequences.  This might be lower if the team needs to respond to issues quickly.  The need for completion is driven by the business's need for predictability.  This *doesn't* mean finishing 80% of the work of the time.

https://www.mountaingoatsoftware.com/blog/when-kanban-is-the-better-choice

Teams should experiment to find the best framework for them, not prescribe solutions.  Kanban requires less managemnent buy-in and has less concepts.  It works well in immature agile environments with little flexibility.  It's ideal for small teams, or teams with large numbers of types of work that can't all be brought into a cross-functinoal team.  People over-focus on the kanban board visualisation, rather than the processes.

https://www.mountaingoatsoftware.com/blog/organizations-that-work-on-fewer-projects-at-a-time-get-more-done

Organisations typically take on large numbers of projects concurrently, and would work more efficiently if they focused on a small number at a time.  This can happen because they want to say "yes" to a project, without considering that this means deprioritising something else.

https://martinfowler.com/articles/201904-end-golden-age.html

Conference AV has gotten less user-friendly, with venues wanting to present slidedecks from their own hardware.  MF's presentation software shows timing information, previews of next slides, allows skipping sections based on the presenter's feeling of timing, and other transitions.  The controls make a difference, typically just a forward/back clicker.  Slides should be a "visual channel" which reinforces the "audio channel", not the main focus.

https://martinfowler.com/articles/domain-oriented-observability.html

DOO means instrumentation of business logic to extract business logic data, such as logging, usage metrics and analytics.  This is in addition to generic observability, but is necessarily bespoke.
This can be achieved without mixing instrumentation with business logic by creating "domain probes", facades over logging systems with interfaces expressed in domain terms.  These will make logging code more testable, and encapsulate the low-level logging systems from the codebase.  Their calls might want a request context object - this could include request info (request ID, user, timestamp, ...) and system info (version, hostname, ...) and possibly feature flags to enable A/B testing.  This could be passed in through a constructor or with a method call - it's important to isolate this from the business logic, so it doesn't depend on the contents.
Rather than having the Domain Probe make direct calls to the logging systems, it might be better to have the DP (or the business class) post events onto topics, which the logging systems consume.  Could implement it with AOP, but this is probably not a good fit for domain-specific measures, it's more suited to generic metrics.