4 ms·
Actually, the book agrees with you. There's very little evidence to support having a ridgid set of rules to follow when programming. There are a few high-level
by TrinaryWorksToo 6y ago
Actually, the book agrees with you. There's very little evidence to support having a ridgid set of rules to follow when programming.
There are a few high-level take-aways from the recurring patterns seen in the analysis;
these include:
• there is little or no evidence for many existing theories of software engineering,
• most software has a relatively short lifetime, e.g., source code is deleted, packages are
withdrawn or replaced, and software systems cease to be supported. A cost/benefit
analysis of an investment intended to reduce future development costs needs to include
the possibility that there is no future development; see fig 4.24, fig 5.7, fig 5.52, fig 5.69,
fig 6.9, fig 3.31.
Changes within the ecosystems in which software is built also has an impact on the
viability of existing code; see fig 4.13, fig 4.22, fig 4.59, fig 4.61, fig 11.76,
• software developers should not be expected to behave according to this or that mathematical ideal. People come bundled with the collection of cognitive abilities and
predilections that enabled their ancestors, nearly all of whom lived in stone-age communities, to reproduce; see chapter 2.
- aard 6y agoThis is good to know. I should jump into the book. I may have gotten the wrong impression from the summary -- the quotes that I shared. I think a scientific effort to look at the many practices that are currently in vogue is very much needed. So many are taken as gospel truths and lorded over people in the name of science-- but they really aren't supported by any rigorous science at all. If this book points that out, than I am all for it. Especially if the book has more a system thinking approach. Many studies isolate one practice (pair programming, code reviews, etc..) and can show benefits, but they ignore the systems they function in. Apparently opposite approaches, supported by the right personalities and environments can often be equally effective. From your comment, it looks like there may be some analysis like that too.
- deleted 6y ago[deleted]
- TrinaryWorksToo 6y agoI like reading about ESE (empircal/evidence-based software engineering) for precisely these reasons. For example, someone found that SOLID programming didn't offer much of a benefit to code readability. This is my favorite talk on it: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/
- jt2190 6y agoI had “lost” that excellent talk. Thank you for posting this.
- specialist 6y agoNice summary. Thanks. I might even skim read the book. Sounds like a more rigorous version of Alistair Cockburn's post mortem on the non success of CASE tools. Forget the title, but the punch line is: Methodology, processes, and tooling are moot. Talented people are somehow able to make any given system work. He uses phrasing like "people are the first order determinant for success". The book I want to read compares the folk theories and fads of software development with other democratized fields. Like education reform. How noobs, wannabes, rejects, and grifters fight over cheddar, slak, and fame. Where any consideration of form, fit, function, and ROI is ruthlessly punished and expunged. Said another way, the only consistent thread in my career is an ever increasing number of people, who are constitutionally incapable of ever shipping product, telling me with complete certainty how I should ship product.