Tagproduct management

Culture of appreciation in dev communities

Github recently released its annual report – Octoverse 2018. Ben Halpern descried an interesting fact about the use of emojis in in Github issue tracker.

According to Github infographics in the report, “the kindest” development community is Ruby developers. In a sense of support and appreciation for other developers via the use of emojis.

Some might say that this metric won’t say much about the “the kindness” of the community. So you might consider also the age distribution of the developers. As younger generation use emojis more often, I would still consider Ruby programming language as a young one (it’s mid 90s). 

On another hand, showing some basic appreciation to someone’s work would retain these people contributing to the community.

People often forget that most of open-source projects are voluntary. So you have to give some feedback to contributors. 

On the contrary, it wouldn’t mean that the world is all unicorns and rainbows. Scott Gilbertson from Wired magazine published an article about the most “swearing” programming communities back in 2011. 

C++ takes top honours, but just barely. Ruby and JavaScript are neck and neck behind C++. 

Wired magazine

We’ve been trying to adapt culture of appreciation in Qobo, whenever we receive contributions from in the wild. So far, we managed to keep our WTF/minute ration quiet low, and show as much positive feedback as we could.

So, whenever you contribute to any of our projects – don’t forget to buy us the beer. It will definitely boost the approval speed  of your pull requests. 

Indiana Jones GIF - Find & Share on GIPHY

Code Churn: post-release defect elimination

Among numerous metrics on code evaluation (like CRAP index) in product lifecycle, code churn seems to be the one to look for while dealing with post-release and legacy code elimination.

Code churn helps you to evaluate file changes across builds.

 Code churn is a good predictor of post-release defects. Thus, it’s a warning sign if you approach a deadline while your code churn increases. That’s a sign that the code gets more and more volatile the closer you get to your deadline. You want the opposite. You want to stabilise more and more code the closer you get to delivery.


Code Churn features

One of the features of code churn – is bottleneck finding across developers and tasks. Low commit rates per author can signal the management, that there’s some sort of problem going on:

  •  Task ambiguity that prevents to complete the task, indecisive stakeholders
  • Technical issues within the platform, preventing on completing the task
  • Legacy code that remains in the product, and possible technical debt increase
  • Under-engagement

Ben Thomson in his post about code churn, provides few graphs, illuminating code impact on productive/churn code across release cycle. As an example, I’ve used CodeScene service, to test code churn on one of the plugins I’ve worked a lot back in the days (hopefully will have time to get back to it soon) – cakephp-calendar.

Calendar Sample

cakephp-calendar code churn graph

As we can see, March-April was a major rewrite of the plugin, that followed next spike occurring in July.  March re-write made the code more fragile. If we dig deeper, we can see that an overall complexity of March-April release was drastically decrease. Here’s one of the examples:

complexity graph of CalendarsTable.php

It’s still quite high, but it’s nothing comparing to what it was. Still, the code was in semi-prototype mode.

Apart of CodeScene service, there’s a specific churn-code composer package for PHP-based projects, that might be more useful for developers.

HubSpot: Gatekeepers and Gardeners

HubSpot tech blog published great article on job balancing and tech leads paradox of gatekeepers gardeners. You might be a gatekeeper if:

1. your team regularly waits for you to review their PRs.
2. your team waits to do the next thing assigned to them instead of taking initiative to find projects for themselves
3. you hesitate to go on vacation because you’re concerned your team will struggle in your absence

On the opposite. A gardener might:

1. Forego reviewing work, or let other members of the team take on the responsibility.
2. Let the team handle their own task management, trusting they understand the needs of the customer, business, and team
encourage members to build relationships on and off the team.
3. Let the team experience failure, trusting in their accountability to fix their problems and learn from their mistakes
4. Have their team take on grungy work along with the “fun” work, because they understand the value of it

Great overview of these two roles people occasionally take once becoming managers/tech leads.

Main Software Engineering cornerstone: Quality

Recently Paul M. Jones published great article on the Software Engineering major conflict between Business and Software worlds: Product quality that perfectly matches Robert L.Glass book I’ve been recently reading on “Facts and Fallacies of Software Engineering“. If you still didn’t read it – strongly recommended!

Just few excerpts on the article:

They [engineers] have a reputation to maintain. Low quality for their kind of work is bad for reputation among their peers. (Note that their peers are not necessarily their employers.)

They understand they may be working on the same project later; higher quality means easier work later, although at the expense of (harder? more?) work now.

And on the other side (dark side?..):

The reputation of the payer is not dependent on how the work is done, only that the work is done, and in a way that can be presented to customers. Note that the customers are mostly not the programmer’s peers.

Work fuel: what really motivates us

Seth Godin published once again a great article on work/life motivation.

  • Becoming a better version of yourself
  • Catastrophe (or the world as we know it will end)
  • Connection (because others will join in)
  • Creative itch (the voice inside of you wants to be expressed)
  • Dissatisfaction (because it’s not good enough as it is)
  • Engineer (because there’s a problem to be solved)
  • Generosity (because it’s a chance to contribute)
  • Possibility (because we can, and it’ll be neat to see how it works in the world)
  • Selection (to get in, win the prize, be chosen)