Making Software: What Really Works, and Why We Believe It Paperback – 30 Oct 2010
|New from||Used from|
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Customers who bought this item also bought
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Would you like to tell us about a lower price?
If you are a seller for this product, would you like to suggest updates through seller support?
About the Author
Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in free software and open source technologies. His work for O'Reilly includes the first books ever published commercially in the United States on Linux, and the 2001 title Peer-to-Peer. His modest programming and system administration skills are mostly self-taught.
Greg Wilson has worked on high-performance scientific computing, data visualization, and computer security, and is currently project lead at Software Carpentry (http://software-carpentry.org). Greg has a Ph.D. in Computer Science from the University of Edinburgh, and has written and edited several technical and children's books, including "Beautiful Code" (O'Reilly, 2007).
There was a problem filtering reviews right now. Please try again later.
found something out about writing software, in a way that
gives you a pretty good idea of what the study really found,
and what it didn't find. Others describe studies and surveys
that expose gaps in our knowledge, so you can spot cases
where people are writing things that nobody knows for sure.
I like dealing with proper facts, not opinions, and I like being able to look at the details of what was done to clarify my understanding of the writeup, so I think this is a big deal. Here are three topics that happened to stick in my mind:
1) Nobody really knows how to do effort estimation, not even
the people with quantitative models (Chapters 1, 3, 6, 15).
2) The usability of tools depends a lot on their users, how
they are used, and for what - so tune or select with
particular scenarios in mind? (Chapters 14, 29)
3) Code review really does work - in fact, even doing a code
review on yourself is worthwhile (Chapter 18).
Most helpful customer reviews on Amazon.com
Okay, I don't think that actually convinced you to buy this book, so I should explain why. Let me start by asking a question: is code duplication - copy-pasting code - a bad practice? Most people would say yes. Question two: does the flue vaccine protect you from the flu? Again, most people would say yes. Final question: which of the two are you more confident in? "Vaccinations work" is backed up by rigorous studies and controlled trials. "Code duplication is bad" is backed up by anecdotes and common sense.
It's also wrong. Godfrey and Kasper have tentatively found that in many cases, code duplication leads to more correct and maintainable code than practicing DRY or adding abstractions. Trusting our common sense is seductive but easily leads us astray. Belief without empirical evidence is just faith.
Unfortunately, researching software engineering is extremely challenging. Challenging enough that many of us programmers think it's impossible. And many of us who think it's possible also think it doesn't affect us, that there's not much we can learn about our day-to-day jobs. _Making Software_ is about the research and why it matters. The first five chapters are about how software research is done, especially how we compensate for the complexities of the field. The rest of the book are papers about specific topics. The papers cover a wide range of research methods, so you can see how researchers use ethnographies, data mining, etc. It shows that software research can, in fact, be done.
This would make it worth reading for fans of the field. What really makes the book stellar is how much conventional wisdom the papers break. Group code review is a waste of time. Open plans are (sometimes) more productive than private offices. Up-front architecture beats extreme programming. And copy-paste sometimes beats DRY. Of course, you're free to argue with any conclusions you disagree with. Every paper helpfully includes the threats to validity, so you know the weaknesses and limitations of the paper. But we have to be careful when doing so, because we're the ones without evidence.
If you are at all interested in the empirical side of software engineering, you should read this book. 0 out of 5.
The editors of this book do a great job of explaining what we can and can not expect from research. They also adopt a very pragmatic mindset, taking the point of view that appropriate practice is highly contextual. Research can provide us with evidence, but not necessarily conclusions.
Beyond the philosophical underpinnings, 'Making Software' outlines research results in a variety of areas. It gives you plenty to think about when considering various approaches on your team. The chapter 'How Effective is Modularization?' is worth the price of the book alone.
I recommend this book for anyone who wants to learn how to think rigorously about practice.
Making Software presents to each chapter a good experience for software industry and professionals in this area.
I recomend it for academics and professionals.
The kindle version of this book is very sloppy. We'll start at the beginning; the table of contents is needlessly indented. I consider indenting content that crosses several pages questionable in any occasion. This makes it even longer than it already is because chapter titles now often need two instead of one line. The book has links to the chapters, but counting that as an advantage in a digital version is like praising page numbers in a hard copy.
The book also offers links to references, but these sometimes span entire paragraphs or pages instead of just the author and year. This also happens to other links throughout the text.
Tables are not properly adjusted for the kindle, last characters of words are on new lines, columns headers are on the previous page, and sometimes columns are just cut off forcing you to decrease the font size. That shouldn't happen at the default font size. Chapter 12 includes an example of all of these.
Now that we're discussing chapter 12; the Clinical TDD Trial References are placed under a bibliography header on the next page instead of under that header (where they belong, as verified with a hard copy). This leaves a blank page. All other chapters have a single references header that avoids this problem.
The book is readable, but it's a very sloppy.