tl;dr:The highest priority adoption factor for 4 types of internal tools: (1) For build tools, it is whether the tool is highly configurable. (2) For continuous integration tools, it’s whether the tool is compatible with the technologies developers use. (3) For infrastructure as code tools, it’s how visible the usage of the tool is within the organization. (4) For version control tools, it’s whether the tool fits well with the way developers work.
tl;dr:The first part describes the categories of tech debt and the second part explores how categories may be measured, providing insights on how to determine whether teams are struggling with technical debt and the types of tech debt they’re struggling with. The final part of this paper provides several tactics that may help reduce tech debt.
tl;dr:The 3 pillars are: (1) Reducing friction: minimizing obstacles, inefficiencies, and complexities in the development process. (2) Optimizing workflows: streamlining processes, automating repetitive tasks, and integrating tools and technologies. (3) Enabling a state of flow: creating an environment that fosters concentration, creativity, and intrinsic motivation.
tl;dr:Abi recommends to better communicate and manage tech debt by: (1) Moving away from using the phrase “technical debt.” (2) Defining what the problem really is. He explains why in this post.
tl;dr:Based on a study with Google engineers, the best predictor of flow is “focus time:” performing a number of similar actions in a given window of time. Researchers also identified 3 practices for facilitating flow: (1) Schedule management. (2) Goal setting so engineers are working on tasks that feel fulfilling. (3) Giving time to “get into flow.”
tl;dr:“There are cases in which individual teams may find cycle time useful. However, using cycle time as a top-level performance measure that is pushed onto all teams is counterproductive. To actually improve performance, leaders should focus on measuring the friction experienced by developers and removing the bottlenecks that slow them down.”
tl;dr:“CEOs don’t know or care about the technicalities of engineering measurement; what they really want is a way to have confidence that you’re accountable for the millions of dollars they are spending on engineering.” Abi argues that you should be concerned about 3 types of metrics as an engineering leader: (1) Business impact: Current or planned projects, and project roadmap. (2) System performance: Reliability, speed and user experience. (3) Developer effectiveness.
tl;dr:"Ownership is negatively correlated with the number of bugs, and the more shared the file ownership the higher the likelihood that it will contain code defects. This trend is also supported by the fact that for all projects studied, the number of contributors is positively correlated with the number of bugs." Abi provides 4 management recommendations.
tl;dr:Abi discusses different types of tech debt, signs that tech debt is becoming a bottleneck, and strategies for addressing debt: (1) Transparent information: Technical strategy must be informed by information on signals e.g. business performance. (2) Clear end-to-end ownership. (3) Empowered teams. (4) Lightweight process: e.g. automated checks or architectural peer review to enforce policies and aid developers.
tl;dr:(1) Developer effectiveness is heavily influenced by work environments. e.g. clarity around what to work on, access to quality documentation, tooling. (2) To create more effective working environments, focus on quick key feedback loops. (3) Leadership creates a culture where developers are empowered to make incremental improvements to the developer experience. e.g. open forum to listen to IC’s, dedicated programs for big problems.