I usually quit reading as soon as I see the signs of the Agile Cult: BDD, other TLAs, and the dreaded "pairing" word. In these threads, what is interesting is the meta-reading. That is, it's about the process, the group-think, the methodology...it's never about actual software engineering. Oh, that's right -- I think the Agile crowd has made obsolete the notion of 'engineering'. It truly is all about Agile, to them.
Keep in mind, the author is a self-described Freak.
Sorry, but this article is totally void of a convincing argument for any of the advice therein. What if you're not a BDD convert? What if you actually get more done on a 2 week long branch?
Have you tried using a 2 week long branch on a fast moving repo with a team of 4 developers and 1 designer? It can be tough without a daily commitment to rebase. We see between 15-25 commits a day on master.
The point of the article was to be atomic with commits and to really push to try BDD. I don't care if you are a convert, you will see the benefits when you try to adhere to the principals.
I added a third paragraph that might help with some insight as to why I feel this way.
Going the BDD (or TDD) route first can help you in many ways... They include: finding unintended bugs, ensuring code works the way you want always, helps convey code intentions to other devs, etc, etc.
If you found it was taking too much time, I would suggest you slow down a bit and really focus on BDD for a few weeks, you only get faster by practicing.
We do enterprise software without the enterprise bureaucracy - so adding in agile just takes it back that way.
Ultimately I dont recommend anyone forces themselves into agile/TDD/BDD methodologies. They are systems designed by people to fit their working practices and preferred approach - its impossible to force yourself efficiently into the exact same mindset as someone else...
The best approach is to pick and choose techniques and practices that fit your flow and develop your own way of working. You'll find it's vastly more efficient.
(we have a couple of teams who finish contract work for other companies who's agile techniques just screwed the timetables/delivery :) so I've seen the difference in action)
My point was that this article was large on anecdote and low on data. Our profession has a ridiculous susceptibility to both buzz and bias towards things we've come across the most recently. That being the case it's even more important to provide hard, measurable, ideally reproduceable results.
If we want to consider ourselves scientists or engineers the worst way to convince anyone of anything is "trust me, it works" or "it worked for me so it will work for you."
Keep in mind, the author is a self-described Freak.