Evidence-based Software Engineering: based on the publicly available data

We never really need it to. That’s one of the few benefits of writing software in the public sector. We don’t need to expect an explosive growth in users.

We’ve seen 10.000 additional citizens move to our area over 5 years, so there is growth, but it’s far from everyone of them who would interact with a single solution that we wouldn’t buy from the private sector through public procurement.

> That, sadly, won't scale.

You're contradicting the UNIX philosophy: make programs so small that they're inherently simple (or so simple that they're necesserily small). I think that's what the other commentor meant and that does scale.

• introduces a subproblem, that would be solvable but for one tool you're currently missing;

• introduces the tool you'll need to solve the subproblem;

• explains the tool in the process of using the tool to solve the subproblem. Only explaining as much of the tool as is necessary to solve the subproblem — more can be explained in later subproblems.

Sadly, I find that most books like this first introduce all the tools you'll need; teach them all thoroughly (including teaching stuff you won't need at all, because it's part of the explanation as traditionally taught); and then go about solving all of the subproblems using all of the tools, in a pretty random order. So the first half ends up boring, and the second half ends up messy and hard-to-follow.

But I'll happily go down that road. The 10x claim ("the most productive engineers are 10x more productive than the least productive") is ridiculous on its face; the least productive are zero or negatively productive. There are people who can't program at all, and there are people who actively detrimental. Therefore, two things are clear:

1. The correct statement is "the most productive engineers are infinitely more productive than the least productive."

2. This is useless information.

A more useful statement would be "the most productive engineers are x% more productive than the median." Or even a histogram—that would be super useful!

But, it turns out, there is no way to measure real-world engineer productivity, so any quantitative claims are, in fact, utter bullshit.

And, if you look at the original research that McConnell cites, that turns out to be true. IIRC, the study was comparing the how long it took to debug programs when using a time-share system vs. a batch-processing system.

(To be clear: I'm arguing about the claim, not the variations in productivity. Obviously, people have variations in productivity. But there is no rigorous evidence for the magnitude or nature of those variations.)