3 ms·
This well written book from O'Reilly covers the same subject: https://www.oreilly.com/library/view/making-software/9780596808310/ https://www.oreilly.com/librar
by neves 5y ago
This well written book from O'Reilly covers the same subject: https://www.oreilly.com/library/view/making-software/9780596808310/ https://www.oreilly.com/library/view/making-software/9780596...
It is from 2010, I don't know if their is really new things on the subject
- muench 5y agoOne of the editors of that book wrote about Derek Jones’s book “I think (at least I hope) this will influence software engineering education [more] than anything I've ever done” https://twitter.com/gvwilson/status/1326190553738977281?s=20 https://twitter.com/gvwilson/status/1326190553738977281?s=20
- jdlshore 5y agoI’m not so sure about that book. It includes Steve McConnell’s claims about 10x productivity, which Laurent Bossavit thouroughly and convincingly debunked in his book, The Leprechauns of Software Engineering. A bunch of citations isn’t the same as evidence. When I dig into software studies, I find all kinds of issues, ranging from subjects of convenience (the professor used their undergrad class for their study) to industry studies that don’t define their terms. (e.g., MS did a large empirical study of TDD, but never defined how TDD was practiced—this is relevant given the misunderstandings of TDD that exist, particularly at Microsoft). I didn’t read the rest of the book—just looked at the blurb, winced at the inclusion of McConnell repeating his 10x claim, and read his chapter—but my default stance is to be highly skeptical of academic software engineering, and even more skeptical of popularizations. Edit: I’ve just glanced through OP’s book, and it looks like an impressive piece of scholarship. I remain skeptical of academia’s ability to teach much of interest regarding software engineering, though. (They spend a lot of words on Waterfall and traditional project management. Their words on the Agile-kinda stuff companies actually use today? One paragraph, paraphrased: “there is no data, we have nothing to say.” Not the authors’ fault, but sums up the irrelevance of academia to real-world SE, in my mind.)
- feoren 5y agoI'm not sure how you can "debunk" something that so many people have directly observed, but our ability to measure a software engineer's productivity is so awful that I'm willing to consider the possibility that we're all just wrong. Are 10x engineers just good at appearing productive then?
- jdlshore 5y agoHe debunks McConnell's claims, which are specifically about 10x research, not the 10x claim itself. 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.)