Reddit reviews Making Software: What Really Works, and Why We Believe It
We found 15 Reddit comments about Making Software: What Really Works, and Why We Believe It. Here are the top ones, ranked by their Reddit score.
O Reilly Media
A shorter (and better) version of the talk is online at http://software-carpentry.org/4_0/softeng/ebse/. If you want to keep up with the latest in empirical studies of programming, check out http://www.neverworkintheory.org/ (where we're blogging once or twice a week about recent findings), or have a look at our book "Making Software" (http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321) which collects the most important findings, and the evidence behind them.
Can't speak for the whole subreddit, but my personal hatred towards him comes from Martin being a snake-oil salesman.
Take his 3 "laws of TDD". Advertised as a practice equivalent to doctors washing their hands, results in horrible and unmaintainable test suites (I've seen plenty of tests whose idiocy couldn't be explained other way than those rules)
Take his "architecture" lectures. Advocating programming in ruby on rails while abstracting away everything about rails or the web or the database, or anything you didn't define yourself. In principle to enable testing and be able to run the code outside the web. In practice: https://youtu.be/tg5RFeSfBM4?t=299 The lecturer says that the architecture in practice is "horribly complicated" and that Bob had only a single implementation of the architecture, which he couldn't share. That didn't stop him from continuing with his lectures.
Take his blogposts (an example: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html) Awful strawmans (this terrible architecture i drew is what you propose), cringeworthy writing style (lengthy discussions with made up opposition instead of real one). Unfalsifiable theories: "Is is only programmers, not TDD, that can do harm to designs and architectures.". That sentence is always true, either you succeeded and therfore TDD works, or you failed and TDD had nothing to do with it. No data to backup his claims "TDD works." - well there are plenty of publications that disagree (see chapter 12. of https://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321)
Take his SOLID principles. While some of them are well defined and can be applied meaningfully (Liskov substitution principle), the Single Responsibility Principle has definition so weak and useless it's ridiculous.
Meta-analysis of over thirty studies found no consistent effect from TDD. One clear finding was that the better the study, the weaker the signal.
Greg Wilson's lecture: http://vimeo.com/9270320
and book http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
Wilson's post about the subject: http://www.neverworkintheory.org/?p=139
>I’m still not sure what to think about test-driven development. On the one hand, I feel that it helps me program better—and feel that strongly enough that I teach TDD in courses. On the other hand, studies like this one, and the other summarized in Erdogmus et al’s chapter in Making Software, seem to show that the benefits are illusory. That might mean that we’re measuring the wrong thing, but I’m still waiting for one of TDD’s advocates to say how we’d measure the right thing.
I think posting material like this with no context is silly, but I upvoted this anyway because I recommend these books often. The Introduction is very short and explains better than I could here why the books were written. The quality of the chapters vary, but they are mostly all worth reading. I'm excited for the upcoming The Performance of Open Source Applications, although I haven't heard any news about its progress in a long while.
One of the editors, Greg Wilson, did some research into how we can be effective programmers. Basically, continuing the research that books like Code Complete were based on. He wrote an excellent book Making Software: What Really Works, and Why We Believe It. He is also involved with the community blog It Will Never Work in Theory, which is tag-lined as software development research that is relevant in practice.
> there are real studies
have you read http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321 ? It's really interesting.
I really like Making Software: What Really Works, and Why We Believe It. It can be a little heavy at times but it's worth the read. If you want a light introduction to it, there's an extremely good talk that sort of introduces it as a side effect, What We Actually Know About Software Development, and Why We Believe It's True. Even if you don't plan to read the book, I recommend watching the talk. It literally changed the way I live, and I now live in less of a hand-wavey world and more of a firm, fact-based world.
The book that he takes about that was about to be published is here:
http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
Not an opposite view, but IMHO definitely worth quoting on this matter:
> If more than 20-25% of a component has to be revised, it's better to rewrite it from scratch. (Thomas et al, 1997)
It's Greg Wilson, author of "Making Software: What Really Works, and Why We Believe It"
Yeah so more of the kind of work this guy is doing:
https://www.youtube.com/watch?v=uEFrE6cgVNY
and greg wilson has a book that reviews this idea:
http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
Senior Level Software Engineer Reading List
Read This First
Fundamentals
Development Theory
Philosophy of Programming
Mentality
Software Engineering Skill Sets
Design
History
Specialist Skills
DevOps Reading List
Good talk and I'm left wondering what's the book's name.
Edit: Found it.. http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321/ref=la_B001H6PNGM_1_2?s=books&ie=UTF8&qid=1453037170&sr=1-2&refinements=p_82%3AB001H6PNGM
I think most is kind of a rough statement. Granted there were some truly gifted people in the 70's that rocked our world.
I think we have a LOT of research papers that we sift through and the legacy papers tend to stay highlighted in time. I can imagine if you sifted through everything that existed back then, you may be saying something similar.
I've found a few great ones and if you are heavy into software engineering, you may share the enthusiasm towards a book that came out several years ago: Greg Wilson - Making Software: What Works and Why we Believe it
He also has a talk where he references some of those papers: Greg Wilson talk
He comes off strong, but he backs it with research which I appreciate. It's more about bringing data to the table if you have something you'd like to discuss. Somewhat heavy handed, but there are good papers that I've read referenced there.
The continual evaluation of Conways law and it's research still holding true today is something that I continually enjoy (Although originating from a 1967 study reinforcing your point of seminal papers from that era)
Article doesn't tell you how, it's more like a handful of thoughts on how to do so, without any real data (as the author admits)
>But I think you should take more away than a handful of application-wide metrics. You should take away a preference for statistical and empirical consideration. Figure out how to quantify trends you observe and form hypotheses about how they impact code quality. Then do your best to measure them in terms of outcomes with the application. We lack a laboratory and we lack non-proprietary data, but that doesn’t stop us from taking the lessons of the scientific method and applying them as best we can.
Someone has already done this. Read chapters 8, 9, and 23 of Oram and Wilson's Making Software
http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321/ref=ntt_at_ep_dpt_2
Bok skriven av samma person.
Check out Making Software: What Really Works, and Why We Believe It. Haven’t read it myself.