Comment by junke | Hacker News Reader

Comment by junke | Hacker News Reader

Parent Full thread

While I agree with the content, I dislike the straw-man pattern that is so commonly found: "you can use method A stupidly or method B (my favorite) intelligently. Hence method B is the best."

Take for example:

> Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute.

You have also option 3: Come up with a specification (not design) for all the components up front in such a way that it minimizes integration risks. Split tasks and define interfaces and/or protocols so that the work can be developed in parallel. Still, try to follow up with the changes in other branches and keep your work up-to-date with major changes that may happen in the main branch. Try to merge to see if there is any conflict, but don't push half-work. However, if you have to modify a main component that is used by other in order to implement your thing, and that change can be merged back safely, do it as soon as possible.

Author here. FWIW, that sentence "Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute" is actually the exact opposite of a straw man: it's a real occurrence I witnessed first hand at a number of companies (if you want to hear all the gory details about one of them, check out the book: http://www.hello-startup.net/). There certainly are companies that are able to make feature branches work for them the way you described, but based on my personal experience and interviews with several dozen other successful companies, feature branches usually lead to disaster.

Using one anecdotal experience as proof is not the exact opposite of a strawman.

Similarly: "That one hour you “saved” by not writing tests will cost you five hours of tracking down a nasty bug in production, and five hours more when your “hotfix” causes a new bug."

These numbers don't line up with any experience I've ever had. In my opinion the value of testing should stand on its own without having to exaggerate.

> Using one anecdotal experience as proof is not the exact opposite of a strawman.

A strawman argument is an argument no one is actually making, but one that's easy to debate against (to "knock down"). So even "one anecdotal experience" implies there is someone making that argument and it's not a strawman. Moreover, as I said above, it's not a single anecdote, but experience with many, many companies, including ones I worked for directly, those that are the clients of my company (http://atomic-squirrel.net/), and the many companies I interviewed while writing my book. Of course, the plural of anecdote is not "data", but I'm pretty sure that you don't need statistically significant data sets to show your argument isn't a strawman.

> These numbers don't line up with any experience I've ever had. In my opinion the value of testing should stand on its own without having to exaggerate.

If anything, it's not an exaggeration, but an underestimate. I can't count how many hours I've lost to debugging that could've easily been saved by a handful of automated tests. But perhaps you're a better programmer than I am, and I envy that your code works perfectly regardless of whether you write tests or not.

> I can't count how many hours I've lost to debugging that could've easily been saved by a handful of automated tests.

Undoubtedly, but be careful you're not suffering from confirmation bias, are you properly accounting for all the tests you wrote that never detected an issue, where they didn't save tons of time in a major refactor (because it never happened)?

> But perhaps you're a better programmer than I am, and I envy that your code works perfectly regardless of whether you write tests or not.

http://blog.dilbert.com/post/141657128476/the-sarcasm-tell-w...

Reply on news.ycombinator.com