ISBN: 9780596808327
Buy on O'Reilly
Found in 7 comments on Hacker News
ruraljuror · 2015-11-24 · Original thread
It seems a lot of these discussions surrounding testing are very anecdotal; this link being a prime example. I remember hearing an interview with Greg Wilson regarding his book Making Software, [1] the premise of which is to apply a more rigorous methodology to understanding what makes software work.

If I remember correctly from the interview (I think it is here[2]), one conclusion was that TDD doesn't have a clear benefit when you add it to a project. On the other hand, in a survey, TDD projects are more likely to succeed because it is a habit common to good developers. I hope I am capturing the subtlety there. Essentially, TDD is not a silver bullet, but rather a good habit shared by many good developers. That was enough to convince me of the merits.

It's another problem altogether to try to institute TDD for a project, especially for a team. Like so many things in programming, TDD could be used and abused. The same could be said for JavaScript or [insert proper noun here]. If misunderstood or used incorrectly, TDD could be a drain on the project. A benefit--and this ties back into the idea of TDD as a habit--is that it forces the code you write to have at least one other client. This requirement would alter the way you write code and arguably for the better.



chas · 2014-09-21 · Original thread
If you want an overview of the ideas behind this sort of research and a quick summary of some results, Greg Wilson gave a great talk on it[0].

I haven't read through the site to see what is there, but software engineering methodology and technique research* uses techniques from research of management techniques in business, making it closer to psychology or sociology. For more information, the blog "It Will Never Work in Theory"[1] does a good job of highlighting these sorts of results that are directly useful and has some explanation of the tools they are using to study software engineering practices. The book Making Software[2] goes into much more detail on software engineering research methodologies if you are interested.

*As opposed to CS theory research that could be used in software engineering, which is usually math.

[0] [1] [2]

toolslive · 2013-12-01 · Original thread
It was mentioned in this talk: and in the corresponding book "making software"

have fun.

mikebike · 2013-04-25 · Original thread
There's "Making Software" by Oram and Wilson:
icefox · 2012-08-23 · Original thread
Well O'reilly recently did put out "Making Software What Really Works, and Why We Believe It" which is a collection of essays backed by not lore, but actual scientific studies about software development. A few topics touched on in the book: • How much time should you spend on a code review in one sitting? • Is there a limit to the number of LOC you can accurately review? • How much better/faster is pair programming? • Does using design patterns make software better? • Does test-driven development work as well as they say? • How much do languages matter? • What matters more: How far apart people are geographically, or how far apart they are in the org chart? • Can code metrics predict the number of bugs in a piece of software? • Which is better: offices or cubes? • Does code coverage predict the number of bugs that will be later found? • What is right/wrong with our bug tracking systems today? • Why are graduates so lost in their first job?

If you haven't yet run across this book I highly recommend you check it out. At least for me it really meshed with my own quest to further delve into the mix of social and technical issues around software development. For more info on the book besides amazon reviews etc I also wrote up a blog entry last year which goes into more depth on the book

spenrose · 2011-11-09 · Original thread
Greg Wilson did a book, which I did not enjoy, on this topic: and a slideshow, which I recommend: .

My take is that there is much to learn from science about how to evaluate propositions regarding software engineering (most, but not all, of them are unsupported) but few new useful ideas.

Another reference along these lines:

Fresh book recommendations delivered straight to your inbox every Thursday.