The one with Google's "theory of quality"
- This week, Abi Noda shared a great Google productivity research paper that aims to summarize the “theory of quality”. Similarly to effort/output/outcome/impact model (which I explored further some time ago in Effort, Impact and Experimentation in Testing article), Google’s research narrows “theory of quality” into a very similar 4 parts:
- Process quality
- Code quality
- System quality
- Product quality
- Another great resource that I found by accident - LinkedIn Developer Productivity and Happiness framework. It provides nice guidelines and examples around the following topics:
- Goals, Signals, and Metrics: A Framework for Defining Metrics
- Developer Personas: A system for categorizing and understanding developers
- Guidelines for Teams Who Create Metrics and Feedback Systems
- Quantitative Metrics: General Tips and Guidelines
- Example Metrics
-
Flaky tests are something the testing community can talk about all day long. In my opinion, the number of such flaky tests relates to the level of skills and understanding the team has. Wayne Roseberry explains that in detail and summarizes that even further saying “Flake is about Control” (or “What happened is something changed which we do not understand or control”). And if you ever saw the hashtag #embracetheflake - Wayne is behind it (and it carries a nice idea as well). Actually, Wayne was talking about test flakiness long ago - there is video evidence from 2016.
-
DevPerfOps Foundation movement that started a month ago with a few memes (#1 and #2) is starting to take shape. Thanks to Scott Moore, there is a DevPerfOps LinkedIn space to follow around this topic as well as a DevPerfOps webpage with its manifesto and related materials. OK, maybe it is not yet in full cylinders, but definitely something to follow in 2024.
-
Finally, I had some time off from work these couple of weeks, and I spent some of that time gaming. I spent some time watching others playing some automation and system design games like “Automation Empire”, “Factorio” and similar ones (as spending an hour or two watching the gameplay felt relaxing and was not really a big investment), but then one game caught my eye and I decided to try it out. It was “City Skylines”. Not only it is fun, but I found it illustrating a lot of software development practices (like agile, iterative progress, bottlenecks, telemetry/observability, etc.) And the most interesting illustration I experienced was the one that at the very start you cannot forecast all the problems that will happen (like train traffic jams, water pollution in pipelines, epidemics, etc.) But they will happen, and then you will need to be agile and ready to react.
So, maybe playing video games is not a waste of time after all? Or is it just me trying to find an excuse? :)