

Be pragmatic with your (coding) time - joshowens
http://railsfreak.com/post/436865973/be-pragmatic-with-your-time

======
eplanit
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.

------
gfodor
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?

~~~
joshowens
gfodor,

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.

~~~
ErrantX
I think gfodor means that this:

 _I know this might sound goofy, but BDD really does work._

Didnt really get explained - why does it work?

(I have to confess one of my teams tried BDD for a while and it didnt really
work out too well. Too much time making or meeting specs :))

~~~
joshowens
ErrantX,

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.

~~~
ErrantX
Nah agile evangalism isn't our cup of tea.

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)

