On the uphill side of things again

2009-01-06T01:42:00Z

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.

TDD vs. Testability Goals

2008-12-12T00:21:00Z

I managed to upset somebody on their blog and felt there wrath for it here. I wasn't trying to do that, he's a pretty smart guy whom I respect and read his articles often. But alas, as all who know me well, know that I speak my mind and at some point or another it rubs somebody wrong because I don't word it correctly or hit a nerve with them. Developers aren't exactly well known for their people skills (especially me) and I think we worked it out like gentlemen in the end as a misunderstanding.

Well anyway, at the source I think Jeremy's response sum's up the point I was trying to make:

Ok, but I would say that that's a matter of design, or at least of using "Testability" as a design heuristic and/or design goal.

This is what I was getting at and where I tend to rub people the wrong way when I don't jump on board whole heartily with the TDD philosophy (I believe in it and support it, but it isn't a cure-all). Many, in my opinion, have (or appear to have IMO) this exclusive 'and' relationship in regards to testing and design; or at least when I read there posts, that's what it sounds like, and this is their pitch behind TDD; that a 'good design' is facilitated by TDD. I disagree with this (to a point) but not to digress I'll bite my tongue for a minute, but to be clear and avoid being chastised: that doesn't mean I'm saying TDD doesn't work, but I wouldn't expect somebody to let 'RUP faciliates good design' or 'XP facilitates good design', or 'SCRUM facilitates good design' fly either if I blogged it here as I don't believe in process being a factor to success or good design, but that people are - and that's all I'm saying.

So lets look at the scenario that I think gets people into trouble sometimes:

You come into a shop of 'gray-beards', and start talking about their design 'isn't as good as it could be' had they used TDD and you begin to show them all this 'great methodology' that allows you to write a test that fails, then write code until it passes, lather, rinse, and repeat and by doing this they're going to have a better designed and stable system in the end. The gray-beards, who've been doing this since the late 70's (or earlier) and probably dated your mother, say 'well that's nice but we don't do that here' or say 'how that's better?'. In your frustration, you didn't notice that they see as much value in testing as you do, but their testing methodology isn't the same, so therefore friction is created when they don't 'get it'. They like the idea of having 'quick/fast/isolated' tests, and see value in it - to a point, but they're not about to give up design patterns which despite what your telling them has gotten them through the past few decades of their career in more languages than you can count just to implement some 'fad' (in there minds - not mine) way of testing that forces them down a certain design path that they have no interest in either for various reasons. So by doing this you've effectively killed TDD from ever being implemented at that particular shop because (and I'm well educated in this subject) rubbed people the wrong way. The rift that has been created can only grow larger if you go out on your blog and start pointing to these people saying they are part of the problem.

Now here's how to have a better chance of success (as I have learned the hard way):

Sell the 'good tests' part of TDD. Sell that you want tests that are isolated (don't require length set ups, or database management), durable (tests that are against functional points of the system, not implementation aspects), repeatable (anyone can run at anytime), fast (run in less than a second in most cases), and maintainable (very few lines of code). Demonstrate that capability using their design patterns and you'll have them hooked because you will of shown them how to cover their rears without having to jump through hoops (in their mind) to do it. As they start doing this kind of testing themselves, they will naturally gravitate to more testable design patterns which we all want in the end.

Now based upon burning myself a few times, and pissing some gray beards off (again, my people skills aren't the best), I've learned to be 'open' to whatever works for a particular shop; let's say I've learned that there is a delicate curve between being a salesman and being a telemarketer, and I've had experiences where myself or some other individual came off more as telemarketers than process champions. I have found now, that when I let those who may otherwise immediately reject TDD as a whole because it's too fundamentally different, instead focus on just writing good tests, they're more likely to play along.

So my point to all of this is exactly what Jeremy brought up - I use testing as design goal, rather than design as a testing goal - and that's where many who tried and failed to sell TDD hit a rock I think. Testability is a goal that all design school of thoughts can get on board with, make that your common ground (get good tests that run fast, test one thing, are maintainable, don't rely on external data/classes, etc). Then once that is hardened and dried, look towards the test first design and other aspects of TDD (test often, write failing test and then code until it passes, write more tests that fail, etc).

Brian P. Johnston

On the uphill side of things again

TDD vs. Testability Goals