4 ms·

> If there is a fix-small-bugs month for example, or a fix-this-client's-bugs push, or a fix-the-bugs-in-the-new-feature campaign. The statistical properties of

> If there is a fix-small-bugs month for example, or a fix-this-client's-bugs push, or a fix-the-bugs-in-the-new-feature campaign. The statistical properties of all these are not identical. For sure -- but these are surely special or assignable causes of variation. That's one of the key insights in SPC: that some variations are ordinary and some out of the ordinary. A "fix the bugs" campaign is out of the ordinary. > Which is to say, different managers will get different means and standard deviations even if the devs change nothing about their work habits. If they have a bad measurement rubric, certainly. But that in turn goes to questions of gauge reliability, a topic about which SPC has a lot to say. I should say by way of agreement that I'm not convinced that SPC can be safely and effectively applied to software development processes. But I'm also not convinced it can't. I don't have a firm, final position on the matter. I would need to apply it for a while and see for myself.

roenxi 3y ago
> For sure -- but these are surely special or assignable causes of variation. Well, for starters they are process changes. The team is working in a different way to normal and, as expected, getting a different result. So it is special variance, but because management has decided that the team should adopt different processes with different statistical characteristics. These aren't one-offs, this is routine for how a well managed software team should perform. Priorities ought to change as the situation develops. And regardless, regular variations are what indicates that a process that isn't under control. If a process is under control, variances should be remarkably rare. Every month in software engineering is out of the ordinary. That is why SPC doesn't work; there isn't a repeatable process to model. There are lots of different processes chained together as vague specifications are continuously translated into logically formal specifications in an environment of continuous renegotiation. It might be possible to make a software team work in a controlled way, but it is pretty stupid - either the team won't fix some bugs to make the metrics look good, or they have to fake bugs from time to time to make the metrics look reasonable. Both are inferior to non-statistical controls of prioritising bugs with reference to how challenging the fix seems likely to be. Say we're going to implement an application. The bugs aren't going to appear as a stable process, there'll be some sort of big wave up front, then successive waves as new features are identified. Eventually the application will be more or less finished and the engineering team will clean up the long tail of bugs. The mean and standard deviation of the work aren't predictable in advance and aren't in control as far as SPC is concerned, because those tools assume steady state. Smoothing that curve from a hill-shape to a flat line is not value-additive; it is bad management in its own right. Resources should be reallocated to fix bugs after a big release and then moved back to dev work. Now there are going to be some situations where SPC isn't crazy, but it is still a bad management tool for software because the SPC teams aren't going to be agile in the face of change, because all their tools will scream blue murder at them for no reason.
- jacques_chester 3y ago
  I have enjoyed a different experience of software development: the team breaks down stories into units of roughly equal complexity. Bugs get fixed first and do not contribute to velocity. Over a medium time frame I've seen this approach produce remarkable stability in velocity measurement. Note that this works by allowing product priorities to fluctuate, but not allowing quality to be a dial that can be turned. A distressingly rare configuration of power.

roenxi 3y ago

> For sure -- but these are surely special or assignable causes of variation. Well, for starters they are process changes. The team is working in a different way to normal and, as expected, getting a different result. So it is special variance, but because management has decided that the team should adopt different processes with different statistical characteristics. These aren't one-offs, this is routine for how a well managed software team should perform. Priorities ought to change as the situation develops. And regardless, regular variations are what indicates that a process that isn't under control. If a process is under control, variances should be remarkably rare. Every month in software engineering is out of the ordinary. That is why SPC doesn't work; there isn't a repeatable process to model. There are lots of different processes chained together as vague specifications are continuously translated into logically formal specifications in an environment of continuous renegotiation. It might be possible to make a software team work in a controlled way, but it is pretty stupid - either the team won't fix some bugs to make the metrics look good, or they have to fake bugs from time to time to make the metrics look reasonable. Both are inferior to non-statistical controls of prioritising bugs with reference to how challenging the fix seems likely to be. Say we're going to implement an application. The bugs aren't going to appear as a stable process, there'll be some sort of big wave up front, then successive waves as new features are identified. Eventually the application will be more or less finished and the engineering team will clean up the long tail of bugs. The mean and standard deviation of the work aren't predictable in advance and aren't in control as far as SPC is concerned, because those tools assume steady state. Smoothing that curve from a hill-shape to a flat line is not value-additive; it is bad management in its own right. Resources should be reallocated to fix bugs after a big release and then moved back to dev work. Now there are going to be some situations where SPC isn't crazy, but it is still a bad management tool for software because the SPC teams aren't going to be agile in the face of change, because all their tools will scream blue murder at them for no reason.

jacques_chester 3y ago
I have enjoyed a different experience of software development: the team breaks down stories into units of roughly equal complexity. Bugs get fixed first and do not contribute to velocity. Over a medium time frame I've seen this approach produce remarkable stability in velocity measurement. Note that this works by allowing product priorities to fluctuate, but not allowing quality to be a dial that can be turned. A distressingly rare configuration of power.