TDD and System. DirectoryServices. AccountManagement

So I am hav­ing a bit of a prob­lem here.  Working on a sim­ple library for a client to help them main­tain their Active Directory entries pro­gra­mat­i­cal­ly.  Started with my tests.  (I took this oppor­tu­ni­ty to spike Machine.Specifications, which I am find­ing that I quite like, but that’s for a dif­fer­ent post.)  Then researched into the APIs avail­able from Microsoft.  At first, I was quite excit­ed about the System.DirectoryServices.AccountManagement name­space added in the 3.5 frame­work, until I tried to inject its class­es into my own.

Now I’m run­ning myself in cir­cles, try­ing to fig­ure out how to test my code with­out cre­at­ing (or worse, delet­ing) accounts on my devel­op­ment box.

The team room and types of developers

The devel­op­ment team has recent­ly relin­quished our indi­vid­ual offices in favor of a team room where we are all work­ing togeth­er.  At first, I was skep­ti­cal that I would be able to keep a high lev­el of pro­duc­tiv­i­ty with the dis­trac­tions that a team room, by its very nature, cre­ates.  I could­n’t have been more wrong.  We quick­ly meshed as a team and have become notice­ably more pro­duc­tive.  (You can see the slope change on our burn­down; it is dramatic!)

One of the side-effects of work­ing in a big room with the rest of the team is that I’ve start­ed to notice the dif­fer­ent devel­op­ment and per­son­al­i­ty styles of the dif­fer­ent mem­bers.  I’ve come up with sev­er­al dif­fer­ent gen­er­al cat­e­gories.  Some peo­ple cross these bound­aries, depend­ing on the situation.

Continue read­ing “The team room and types of developers”