Preface - as a note, at my job we all work remotely in different areas and do most of our communication via IM and phone (yet we still manage to write decent software despite what some would say about that being possible).

One of our uppers has been helping steer the ship where we've been banging the drums on and we've finally gotten to the point where we've got some of our bigger previous obstacles out of the way.   These and other things that have been helping us move in the right direction allowed us to finally start doing 'technical documentation' at the level we want to.   Yeah, I actually like documenting what I do versus cowboying it out.   Paper on a computer erases pretty cheaply and doesn't take long to write or update.

Anyway, me and and one of the guys were IMing and I asked if he needed some work (we've been slow during the holidays and we follow a defined process so we can't just go working on something that isn't approved).   He did, so I sent him some design documents I had been working on in UModel, we briefly chatted on it (like 2 minutes) and he set off to work.

Later on he IM's me and asks if on my copy of the development path we were on (we work on several branches at once - our build and config management is very sound, so this isn't a problem for us) I had created a certain folder yet to hold a new set of class in a new namespace.  I told him I hadn't and that he could go ahead and do it.   It then occurred to me, even though we didn't discuss it, because he had a design document to refer to, I didn't have to tell him to make a folder for these new classes and that they would be part of a certain namespace and would be structured a certain way.  He just knew to do it, we didn't have to babysit each other.   It's been a while since I've been able to work so effortlessly like that, so I forgot how nice that is.  

So I realize this and say 'hey, you know what, we didn't have to spend a long drawn out session talking about this - you just got right down to it'.   He said 'yup'.   And I just said - 'wow, we got good requirements from our BA's, we got a design to refer to, and we're just coding and writing unit tests - man - we should write a book about that and revolutionize the industry; you can write software without just going out and 'doing it' and have something to refer back to when there's a question'.   We both laughed at it and continued happily about our day.

This person is a good developer so I know any changes he needs to make for the tests he creates along the way will make it back into the final design.   Some he'll do before he writes the code, some he'll do after - regardless we'll have 100% code coverage in the end and each test will run under a second and not be coupled to other objects, data, state, etc.

The point of that I want people to take away is to note that I'm not rigidly following any 'pattern' here, I'm just doing what works for this particular project, in this particular setting, for this particular set of developers.  I could easily do this a totally different way if I was part of a different group of people (in fact I have).   My fellow developer in this case isn't following a particular pattern either in the way he writes the code.  But in the end our code will be covered by tests, be extensible (by design) and I know when we do code reviews I'll see good comments and structure.

I guess I'm just going back to what I say to people over and over again: It's people, not process.  It's dicipline, not rules.  It's art, not instruction booklets.  It's the bell-curve, not the purists.

Just food for thought.   Flame on those who want to poke holes.