Microsoft Enterprise Library
One thing I haven’t mentioned about myself yet is that I’m part of the Microsoft Enterprise Library team. I’ve been working on this project since its first day, back in February, and MS has finally taken the wraps off the project. This has freed us up to start talking about it, and talking I intend to do! You can see the blogs of the other Enterprise Library team members at the far left of my blogs. All of them are recommended reading, as they are all very bright, energetic, agile programmers.
What we’ve been doing is taking the Patterns and Practices Application Blocks written by Microsoft, and merging them with similar functionality from an MS partner, and releasing them as a coherent library. This library has a consistent coding style and content, documentation, and has tooling to help with configuration. We’ve been working as a joint team in Redmond for almost 6 months now, and we’re ready for our first release.
You can learn all you want to about what is in Enterprise Library V1.0 here and a GotDotNet workspace coming soon, but I want to tell you about my part in this, and what I’ll be blogging about over the next few weeks or months.
First of all, I was one of the developers on the project. Given that I have 17 years of experience developing software, I was one of the more senior people on the team, but I was still a developer. I consider this to be a great situation, since it gives me to combine the two loves of my professional life — writing code, and helping younger developers grow and improve.
As a developer on this project, I, of course, am responsible for my own deliverables. As of today, that has consisted of the Data Access Block and a reimplementation of the Caching Block to address some issues that came up with the original implementation. I’ve also done code reviews, fixed bugs around the system, and written and reviewed documentation. In the beginning, I was also one of the few main drivers towards agility on this project, insisting on Test Driven Development as a large part of our process, and helping all the other developers on the team learn how to write code test first. (To be entirely fair, Jim Newkirk of NUnit fame is the Microsoft Development Lead in Patterns and Practices, and his voice was heard much more loudly and clearly than mine on this topic. Jim did a great job in starting off the agile approach, and did a lot throughout the development cycle to encourage all levels of the team to stick with the approach every day. Scott Densmore, another MS dev, was the driving force to get developers to adopt it internally, and I was the in-the-room resource for helping folks learn this stuff, as well as the Pain in the Butt coach who helped them stick with it daily.)
What I intend to do over the next little bit is to write about our development process, how being agile helped us deliver a tremendous amount of content in a short amount of time, and how we grew as a team over the project. I’ve already started writing a bit about this, as the previous post about Project-Specific Hearing was taken from experience in the Triangle Lounge, which is what we call our little work room in Redmond. I’ll also talk about technical issues faced and overcome during the implementation, which I’ve also begun doing with my post about the Active Object pattern.
My main goal in writing about these topics is to share with people how it is possible to take a bunch of very different, very strong-willed, and intelligent people, and help them form a very-well jelled team. Through our actions, both overt and covert, we came together to work towards our common goal, but not without a lot of pain, especially in the beginning. But we made it, and I want to tell you how. More on this later…