Posts

Showing posts with the label effective

Effectiveness of code reviews

Image
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...

Quoting Dan North: people don't get blocked, work gets blocked

 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...

Everything is a negotiation

I find that most people employed in ICT know what a negotiation is, yet they inevitably fail to see one, even when it's placed right in front of them. I don't know the reasons (maybe our compulsively rational, binary mindset?) and I don't plan to study them. I will however claim,  rather ambitiously, that if we realize that everything is a negotiation, and deal with it accordingly, we can greatly improve the way we work together, and also be more effective. Some examples: a colleague reaches out to me and suggests we buy support for the Open Source monitoring product we use, because it's critical to our infrastructure. I say no, briefly arguing my reasons. We reach out to another team and suggest a change, they decline it. Are these negotiations? yes! and no! Yes, well of course they are: as the title says everything is a negotiation. At the same time, the conversation stops short of  the discussion with the intent to find a compromise , so it's only just a potenti...