My daughters and I have a phrase we've picked up from some where... probably a movie, but I don't remember which one, which is "you don't even know, you don't even know". We use it liberally to describe a situation where people are talking about stuff they clearly know nothing about, yet they are sharing their opinion about it anyway. It seems strange that this happens... and frankly it happens all the time.
So while speaking in Denver between sessions I attended a great session by Jared Richardson. We got into a discussion on developer perceptions on agile practices such as pair programming, etc. When it occurred to me that this was it... so often developers dislike pairing when they haven't practiced it. They claim they don't have time to write unit test or integration tests... but they haven't attempted it.
It appears that Agile in some circles is getting a bad name... but most of the time it is based on the opinions of someone who thinks they know what the outcome will be... they have thought it through in their head and have come to a conclusion, which has become their opinion on the matter. Sometimes this is further justified through their comments "well I heard that so and so had issues... blah...blah". Sometimes it comes in the early onslaught of pain... either it is new, or their some affect of team storming. The reality is that often new agile teams run a little slower upfront, but end up significantly ahead of non-agile teams. The pain is worth it! (at least from my experience)
So as a community let's make an agreement. If you ain't done it, you can have an opinion... but it doesn't count :) If you think it won't work or if you heard it won't work... you don't even know what you don't even know!
Knowing comes through experience! and as GI Joe says "Knowing is half the battle".
Subscribe to:
Post Comments (Atom)
1 comment:
So true...I think that the philosophy of rejecting a direction based of hear say and of other's experiences transcends just software development. We all tend to get biased based of the information fed to us..
There are times of course, where one can utilize the experiences of creditable 'others' in deciding whether a direction is appropriate or not :-)..and thus making an educated decision. Thinking filters here.
Pair programming is an accomodation of sorts and is often a difficult sell. However, there are times when the case is vital, especially where $$$ is involved. Rather have code that has approval of more than 1 individual..IMHO Pair programming manifest itself as Code Reviews as well.
Regarding writing unit-test, whether its pair programming or not, can't imagine in this day a SDLC enviroment where one can let code get past development without the same. 100% Code coverage is IMHO a bit overkill but as long as critical paths have been covered well, confidence level is margining on arrogance ;-)))
Anyway, I am going to attend NFJS in SLC...ping me sometime..lets meetup Sir...
Post a Comment