This is a list of articles, posts, and tweets that seemed worthwhile to have referenceable.

Useful engineering metrics and why velocity is not one of them ⚓️

• (Lucas Costa, Founder & CEO of Ergomake; 2022 Aug)
• “velocity is a terrible metric because it offers no predictive power and doesn’t help you make decisions.”
• Instead, frames engineering throughput using queuing theory and Little’s Law, focusing on matching arrival and departure rates through the several queues in an engineering workflow, and using cumulative flow diagrams to spot problems
• “There are four metrics you can use to measure the performance of such a queueing system”:
  • “Arrival rate — the rate at which tasks arrive in the system”
  • “Work in progress — the number of items in progress at any given time”
  • “Departure rate or throughput — the rate at which tasks leave the system”
  • “Cycle time — the time it takes for tasks to leave the system”
• “A good metric has three characteristics”:
  • It’s not a target — Instead of determining an end state, it helps determine whether you’re going in the right direction.
  • “It’s actionable — It helps managers make decisions and intervene in a system to generate improvements.”
  • “It has a clear relationship to other metrics with characteristics 1 and 2 — You know how other metrics will change as you pull different levers.”
• “Despite considering these metrics ‘good’, I must urge managers not to:”
  • “Turn metrics into targets — As Goodhart’s law states, when you turn metrics into targets, they cease being a good metric. That’s because people will game the system to make metrics get better at all costs instead of actually fulfilling the organization’s purpose.”
  • “Weaponize metrics — As Deming says, “whenever there’s fear, you get the wrong figures”.”
  • “Use metrics as a substitute to talk to your team and perform qualitative analysis. — Metrics must serve as an “alarm.” They ring a bell when something goes wrong, but it’s your job to determine how to intervene.”

10 ideas for building great culture in a distributed team ⚓️

• (Nathan Barry, Founder & CEO of ConvertKit; 2022 Apr)
• “Build a culture of written, asynchronous communication”
• “Shared ‘no meeting’ days.”
• Set time aside for informal chatter to get to know coworkers
• Automate a detailed on-boarding workflow
• Mandatory fun time off
• Facilitate meetings between random coworkers (e.g., Donut chats)
• Biannual offsites
  • “The biggest mistake I see companies make is trying to get too much work done on a retreat.”

Happy Workers are 13% More Productive ⚓️

• “Research by Oxford University’s Saïd Business School, in collaboration with British multinational telecoms firm BT, has found a conclusive link between happiness and productivity.”
• “The authors state that while the link between happiness and productivity has often been discussed, their study provides the first causal field evidence for this relationship. ‘There has never been such strong evidence,’ said Professor De Neve.”
• “The researchers found that happy workers do not work more hours than their discontented colleagues – they are simply more productive within their time at work.”

Time Pressure in Software Development ⚓️

• (Abi Noda, Founder & CEO of DX, 2023 Aug)
• Summary of meta-study from University of Oulu in Finland on 102 relevant papers: What Do We Know About Time Pressure in Software Development?
• Time pressure gets results within certain constraints:
  • If it’s not too much — otherwise, it actually hurts efficiency
  • if the task actually can be sped up, or its efficiency improved — some are already optimized, at least with respect to the resources available
• The results come at costs though:
  • Quality tends to suffer
  • Changes that would improve efficiency are pushed off
  • Unsurprisingly, time pressure has negative effects on individuals — though more on novices than experts

Painless Functional Specifications — Part 1: Why Bother? ⚓️

• (Joel Spolsky, co-founder of StackOverflow and Trello, 2000 Oct)
• Makes the case for always writing a functional spec ahead of writing code
• “First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project”
• “I believe that on any non-trivial project (more than about 1 week of coding or more than 1 programmer), if you don’t have a spec, you will always spend more time and create lower quality code”
• “…when you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs. What’s worse, a programmer who’s just spend 2 weeks writing some code is going to be quite attached to that code, no matter how wrong it is. Nothing Speedy’s boss or customers could say would convince her to throw away her beautiful converting code, even though that didn’t represent the best architecture. As a result, the final product tends to be a compromise between the initial, wrong design and the ideal design.”
• “Giant reason number two is to save time communicating. When you write a spec, you only have to communicate how the program is supposed to work once. Everybody on the team can just read the spec.”
  • “When you don’t have a spec, all this communication still happens, because it has to, but it happens ad hoc“
• Number three giant important reason to have a spec is that without a detailed spec, it’s impossible to make a schedule