Measuring Developer Productivity

This analysis by Kent Beck is worth sharing. 

Measuring productivity is a complex and nuanced problem, and there is no single solution that will work for everyone. The best approach to measuring productivity depends on the specific needs of the organization, such as the goals of the measurement, the resources available, and the culture of the organization. Any attempt to measure productivity must be done carefully, as it can have unintended consequences, such as creating a culture of fear or mistrust. It is important to remember that productivity is not the only measure of success, and that other factors, such as quality and customer satisfaction, are important.

The Design of Data Intensive Applications by Martin Kleppmann (2017)

Since this book was published, a large number of people have spoken to me about it, the topics covered, how great the book is, and why we should all read and discuss how it applies to our work. Someone had me help her organize a book club to discuss only this one book and how it applies to our projects.  I am very embarrassed that I did not read it until this year, The book really is as fantastic as everyone said.   Now I understand all those commit messages and code comments such as "DDIA page 132." I cannot recommend this book enough.  5/5 Stars. The book exceeded my high expectations. 5/5 Stars. 

Martin Fowler on Branching strategies in software

Martin Fowler wrote a fantastic explanation of the best patters for successful merging strategies, including my favorite short-lived feature branches pattern. Make sure to skim this one!

Maps, Territory, and Naming in our Software

I recently started reading through Kai Wai Cheung's book on "Naming things," in software development and wrote about why I am interested here in my blog.  I also gave this keynote presentation about inferring user identity a while back where I touched lightly and obliquely on this topic of naming variables and database fields with words such as "visitor" instead of customer to account for bots.  I have recently come across a few situations at work where the mental models of my peers are unrelated to the reality we are seeing. The problem is amplified by the names we attach to the entities we discuss, and the lack of shared meaning (common understanding ) among the people discussing "the territory" of our business phenomenon.

The Map Territory relation

From wikipedia: 

The map–territory relation describes the relationship between an object and a representation of that object, as in the relation between a geographical territory and a map of it."

In the example from my presentation on inferring a person's identity from their behaviors instead of relying on their cookies, sign-in credentials, what they have, what they know, etc. I recommend that database fields, object names, code variables, and other naming of the entity connecting to your web site be labeled "visitor" instead of "user."  And instead of confusing an account with a single, registered "user" we should carefully name the entity an account.  After all, one person or bot may have many accounts, and one "household," "shared," or "company" account may have many different people or programs operating using that account.

The same many-to-many mappings exist for devices to humans (or bots) and most other identifiers.

Cause - Effect Confusion

Among the many, odd business situations I encounter at work, one of the most frustrating is confusion and frequent self-deception about causation, correlation, bias, and the prediction afforded by evidence-based science.  I wrote about one example relating to agile practice a while ago. The "cargo cult" practice or belief that when B follows A that A causes B, or in Latin: post hoc, ergo propter hoc is much worse than one would expect in business.

As always, I welcome your comments, good, bad, and non-sequitor.