unicolet.org

Really interesting research article on the impact of various factors on code review effectiveness. The research focuses on a single product: "analysis of data collected from a (commercial) software project and developers from a single software development company" The findings should be not new to all of us, but, personally, I always appreciate having data to back experience up. All the study findings in one chart The take aways 👇:  Change size : size negatively affects all outcomes of code review that we consider as an indication of effectiveness. Reviewers are less engaged and provide less feedback. Moreover, the duration is not linearly proportional to the patch size, which may affect the quality of code review. Number of Teams involved : code reviews involving more teams have lower effectiveness considering duration and participation, but higher effectiveness with respect to the overall comment density. Comment density by reviewer is slightly higher when two teams are i...

A bad system will beat a good person every time. W. Edwards Deming at a February 1993 seminar.

My motto (has been for a while): There are no stupid questions, only stupid answers

Just like financial debt, not all tech debt is created equal. There is some you want to pay back ASAP and some you can slowly pay back over time just like the low, fixed-rate mortgages one could get in the past decade. Surely, you would not borrow from this guy On the other hand, if you borrowed money from the thug down the corner you'll want to pay him back right away. Credit card debt: you can give yourself some time, until the next sprint. The question is, how do you tell one tech debt from the other?

Via:  https://blog.phylum.io/the-great-npm-garbage-patch/ The Tea protocol started with good intentions as a way to reward open-source contributions, but is ending up badly by polluting package repositories with (lots of) garbage packages. Most of these packages are harmless , but some are downright mischievous as they pretend to depend on the popular axios module, when in reality they're downloading a completely different thing instead. So, besides warming up the planet, now Crypto is also blowing up package repositories with trash. Not all hope is lost however: the key to building good systems is consistency and great error correction . So if Tea protocol recognizes the problem and acts upon it promptly, the course can still be reversed into a (possibly) positive direction.

I've heard or of Codescene through Matthew Skelton who mentioned it in his presentation "Untangling software delivery with Team Topologies, flow metrics, and careful decoupling" .  AFAIU Codescene is a contraption of the title of the book "You code as a Crime Scene" by CTO and Founder of Codescene Adam Tornhill . Illustration from Codescene documentation I was playing around with Codescene and came across a chart referencing a  ws_complexity metric. Curious about how complexity was measured, I asked and they pointed me to this document page:  https://codescene.io/docs/guides/technical/complexity-trends.html#what-s-complexity-anyway  Essentially Codescene measures amount of (leading) whitespace as a proxy for complexity. As they explain this has several advantages, the most important being that it is simple (both in terms of implementation and computation) to implement for almost all programming languages.

 Quoting Dan North on Patterns Of Effective Teams  on standups (he calls them seize the day ): I think Ken Schwaber is being misunderstood [...], so these three questions what did you do yesterday, what are you doing today, and are you blocked? These are the three standard question, he using those sort of questions, it's kind of close, yeah. Unfortunately you're totally missing the point - I do apologize - the questions are these: what work items moved yesterday, what work items are likely to move today, what work items are blocked . People are never blocked, right? If in doubt context switch, if you are worried about which context to switch, have a meeting, you lonely at work? have more meetings. So... people don't get blocked, work gets blocked . [...] You don't measure the workers, you measure the work items, we're measuring the the flow of work through a system...

Disclaimer: I am not affiliated with Unblocked, nor Unblocked sponsored this post in any way. This is my a genuine account of my time spent with Unblocked. I wanted to give Unblocked a try for a while, but never got a good excuse. Last week I came across opslane , which does something I always thought would have been great to have as part a ChatOps setup. Since opslane does not support Prometheus Alertmanager I decided to fork it, and then give unblocked a try. First, I familiarized with the code in a codespace, once I had an idea of how the code is setup I decided to give Unblocked some tasks. The first one was to ask: how do I add a new alert source? BTW, these are the actual questions I used. As far as I can tell Unblocked answer was detailed and accurate. However, before jumping into writing code I needed to assess if my codescene could run tests. We should only touch a codebase after we've ensured it passes tests (it's green), righ...

The most effective way to kill anybody's commitment when they present an idea or work to us is to start suggesting changes. Now it's no longer their idea, and as a result their commitment will be cut in at least half. A reduced commitment will in turn negatively affect execution, then outcomes, and ultimately impact. And we don't want to negatively affect impact. So what we should instead think about is: how much MORE value am I adding? Unless it's an amazing margin (2x), the best course of action is just to say thanks, that's a great idea! How were you planning to execute it and is there anything that I can help with, now or later? Alternatively, if we really want to add something we can ask: what kind of feedback or advice are you looking for from me? By asking in this way we're still leaving the agency - and the commitment - with them. This does not apply only in employee - manager situations, but can happen in lower-stakes interactions too: think code revie...