Links to some of my
best less-inane posts, by subject.
Tips for how to establish a set of metrics that will help you maintain your process health.
Describes how I measure coding productivity, using a process that measures the ‘change’ in every version of every file.
Virginia Apgar saved millions of lives by rating newborns on five categories. The score ”turned an intangible and impressionistic clinical concept into numbers that people could collect and compare.” Discusses how this approach might be used to make code reviews quantitative, comparable, and mine-able.
Teams and hackers can be measured by analyzing the digital traces the process leaves behind. The question is how to measure performance in an ethical and non-threatening way.
If you have more manual tests than you can run with each release, this explains how to use sampling to estimate your pass rate for the tests you don’t have time to run.
Some problems recur endlessly because they fall into a kind of “sweet spot” for failure, where political interest, organizational dysfunction and cognitive limits align. Software estimation is an example. This post focuses on the the role cognitive biases play.
Asks whether the benefits of story points outweigh the drawbacks. Highlights the most useful innovations in agile estimation, but suggests we go back to using actual time measurements.
Explains why projections based on standard velocity calculations will always be too optimistic.
Models and System Dynamics
Agile as a set of practices will only take you so far. If you want to outperform the herd, you need to question every aspect of your process.
A simple, but useful, dynamic model of software development based on system dynamics. Having a clear, mental model like this is the first step towards making progress.
An extension of the rework cycle model that includes customers, scope changes and feedback during the development process.
Highlights the difference between conformance (to spec) quality and design quality - specifying the right product for the market. We often focus too much on the former. Total quality is defining the right product, and implementing correctly.
Looks at the inconsistencies between motivation theory and standard practice.
Working in an engineering team should be challenging and fulfilling. Looks at how management decisions may have an unnecessary, negative impact on employee well-being.