This is part two of the blog series about creating a WPF application using TDD to drive the functionality and MVVM to split that functionality away from the view into something more testable. You may want to read part one if you haven’t already. In this part, we’ll see what it takes to display data on the front page about each player on the softball team. We’re not going to display all their stats, since we don’t need to for the example, but it would be very easy to extend this to do so.

This is a preview of the material I’m going to be presenting at the St. Louis Day of Dot Net in a couple weeks. Introduction For those of you who are reading this blog for the first time, I’m pretty much the St. Louis Agile Zealot. Long hair, flowing robes… you get the picture 🙂 I’ve been advocating Agile and XP in St. Louis since around 2000, through speaking at various user groups and local conferences, teaching at local companies, giving talks in the park, dropping leaflets from airplanes, and so on.

I’m writing an example for a workshop on estimation in an agile context, and I’m considering using the idea of preparing a multi-course meal. I think I like this because it is entirely non-technical, so I can give it to developers, customers, QA, or anyone else without regard to previous technical knowledge. I also like it because there are obvious tie-ins to concepts like freshness, inventory, rapid delivery, and so on.

My good friend, Matt Philip, wrote an interesting blog entry the other day about Six-Word Memoirs By Writers Famous and Obscure. I thought it might be interesting to write about the agile methods, their values, and their practices, following a similar style. So here goes, my own take on Six-Word Memoirs on Agile Values, People, and Activities… Agile: Business plans, developers do, people thrive Agile: Don’t want “resources”, give me people!

A fairly obvious observation hit me today… If you are trying to pair program without also doing test driven development, when do you change roles? When doing TDD with Pairing, there is a rhythm to when the roles switch – see Micro Pairing. But if you’re not doing TDD, the person typing is frequently lost in solving a fairly large problem, they are balancing a bunch of things in their heads, and they have to finish a big thought before they could possibly swap the keyboard with their pair.

This is a true story from a true client I’m working with . The names and details have been changed to protect the innocent… Story splitting Several of us were attending a pre-sprint planning meeting yesterday, trying to flesh out the user stories that the product owner was planning to bring to sprint planning in a few days. They are still pretty early in their agile adoption as well as their technology adoption, so there are lots of questions floating around about process and tools.

I recently finished 6 weeks of coding for a client, and it was heaven! I actually got a chance to code every day, for 6 solid weeks. It was a chance for me to learn C# 3.0, and a chance to work on testing things that are hard to test. It was great! Out of the work, came several interesting observations and coding techniques, all rooted in C# 3.0. Since no one at work has any experience with these new idioms I “invented”, “discovered”, or just “copied”, I’d love to get some reader feedback.

I had what was probably an obvious insight the other day while I was working on my project alone. I’m a team of one, which kind of gets in the way when it comes to pairing. This, unfortunately, has an effect on my final code. Good pairs are adversarial When you find yourself pairing with someone really good, it can almost feel adversarial. What I mean by that is that you can get into a rhythm where one person writes a test, intending to lead his partner down the road of writing a particular piece of code.

OK, so this stuff is different. Really different. So different that i feel like a TDD rookie all over again. I find myself questioning everything that I do, and wondering if I’m going in the right direction. But it’s fun learning something new… When I last left you… When we finished episode 1, we had created a couple of customer tests and had used Interaction Based Testing to drive out the basics of our architecture.

My friend, Jim Newkirk, introduced me to a very nice way of partitioning programmer tests for a class as you write them. Most developers write a single test class for a single application class, and just dump all tests for that class in the same place. This is not as correct as it could be (that’s Consultant-Speak for “that’s just plain wrong”). The accepted best practice is to group together tests that have the same setup/teardown logic into the same test fixtures, which can lead to having multiple fixtures for a single class.

Craig Buchek pointed me to a great paper called, Mock Roles, Not Objects. I thought it was a good explanation of what I was trying to show in my last post. Recommended reading. -bab  

Hi, everyone. I haven’t posted any serious technical content on this blog for a long time now. The reason for this is that I’m now a pointy haired boss most of the time. I spend my days teaching, mentoring, coaching, and occasionally pairing with someone on another team. I miss coding… I really do. However, I’ve been digging into Interaction Based Testing over the past few weeks, and I’ve found it fascinating.

I’m eagerly looking forward to going to Agile 2007 next week. I look forward to this conference every year to give me energy to get through the next year. It’s so much fun to see all my agile friends for a week, hang out, talk about what we’ve learned, drink the occasional beer, and just catch up. If you’re going to DC this year, look me up. I’m in the conference hotel.

Ayende had an interesting post on his blog today about the only metric that really counts, which is maintainability. He made a joke about measuring this property of a system by measuring the intensity of groans that emanate from the team when asked to changed something, which made me laugh. It did bring up a more significant question in my mind, one that I’ve thought about before, and something that I’ve been telling my TDD classes lately.

I’ve been preaching TDD for years, and one of the lessons that I’ve taught over and over is that if a test is hard to write, you have probably bitten off more than you can chew. Comment out this test, try a smaller byte, and come back to this test later. I need to listen to myself more often 🙂 Background It has always been difficult for me to explain to students how TDD works with multiple objects, refactoring, stubs, and the whole shebang.

A team I was managing recently shipped a pretty complex, interactive web site, http://www.sothebyshomes.com . Feel free to check it out and let us know how you feel. During this project, there were a bunch of things that were really hard for us to do, and we invented ways of making them easier. By making them easier, we did them more frequently, and their value to the project and customer increased.

I’ve been leading a team of 5 devs, 1 tester, 2 designers, and 1 customer for the past month or so. During that time, I’ve learned a lot from watching this team grow, in their relationships to each other, and in their ability to work together as a team. What has struck me about this is that all of this happens best if I keep my nose out of it. And this is the hardest part for me.

Asynchrony Solutions is looking for several developers to join our company. Our immediate requirements are: C/C++/Unix/realtime/embedded developer — This is for an exciting, very long-term project where you would have the opportunity to write code in C, Java, and C++ Java or C#/.Net/ASP.Net developer for any one of a number of projects Agile mentors and trainers In addition to technical skills, agile experience is a definite plus. Even if you haven’t ever worked in an agile environment, you should be very opening to learning agile skills and working in such an environment.

I’m leading an agile team through developing a web site. This means that I spend most of my time managing, but on this one occasion I had the opportunity to write some code. The problem We had an image stored in a database that was always either 800×600 (portrait) or 600×800 (landscape). We had a need to render that image on the site either as-is or reduced to one of two other sizes.

(First test post with Windows Live Writer Beta…) Here are the tests for a class I wrote a while ago. This class is used internally by the Caching Application Block inside the Enterprise Library. It has a bunch of housekeeping data inside of it, but the only really interesting behavior in it revolves around determining when an item in the cache is expired. The user is allowed to provide zero or more objects who can determine, in a manner of their own choosing, whether or not the item in question has aged too long and should be flushed from the cache.

There are two ways to break down a project (OK, there are probably more than two ways, but work with me here…) One way is horizontally, meaning to implement an entire application layer at once. This would be like building the entire UI first, then the business layer, then the database, etc. The other way is to implement bits and pieces of all layers over and over, which is like taking a vertical slice through a program — a bit of UI, business logic, persistence, and so on.

I apologize to any readers that I may have left for my extended absence from posting anything of any consequence. It’s been a tremendously long time since I’ve felt that I’ve had the time or the energy to make a long, involved, technical blog post. I do have some coming — its just a matter of finding the time to write them Agile 2006 I was fortunate enough to attend this great conference this past week.

The whole basis of my talk at TechEd is that there are some non-technical rules around which creating good frameworks should revolve. Since I mined those rules from my earlier poll on this blog, I thought I should share my results with you. I give you Brian’s Handy Dandy Rules for Framework Development Clients come before frameworks Ease of use trumps ease of implementation Quality, Quality, Quality Be an enabler It’s a people problem Clients come before frameworks

One of the best parts about working with Ward Cunningham when he and I were at patterns & practices is that I’d get to listen to him, and hear these gems of wisdom fairly often. Now that we’re both gone from p&p, I’m reduced to finding these quotes as they are relayed by others. Here is a quote from Ward that really captures the essence of what it means to write great Agile code:

I’ve been meaning to post this for a while, but I’m finally making myself do it now… I’ll be giving a presentation on “Creating Your Own Enterprise Application Framework” at Tech Ed in Boston, on Friday, June 16 at 9:00 AM in Grand Ballroom A. My talk is based on experiences in my 2–1⁄2 years in patterns & practices and how I believe we most successfully build our libraries and frameworks.

Hi, All, This entry should have something in it for everybody, since I have a bunch of little things to say. Friday is my last day at patterns & practices. I want to thank everyone there who has put up with me for 2–1⁄2 years. The experiences I’ve had there and the friends I’ve made there will last me the rest of my life. And hopefully I’ve left something of myself behind that will help them in their future endeavors.

http://www.waterfall2006.com/ I’ll see you all there! — bab  

Sorry I didn’t get this link out in time for folks to tune in live, but I spaced on it  Anyhow, Peter Provost, Brad Wilson, Darrell Snow, and I did a webcast about a week ago talking about lessons learned during our projects (EnterpriseLibrary and CAB). We ran both of these projects using similar Agile methods, had great results in both, and talked about what went well and what we wanted to improve on for next time.

There has been a lot of controversy lately, both in the blogosphere and on the Yahoo TestDrivenDevelopment group, about whether or not it is possible to due true Test Driven Development (TDD) using VSTS. I’m here to tell you that it is absolutely, completely, totally possible. But it ain’t easy. The point of the rest of this post is to explain why, and to show you another, easier, way. My definition of TDD

My thanks to all who voted on this topic to send a clear message to Microsoft, and to all those inside Microsoft who listened to the complaints and took them seriously. — bab

**Updated – 11/23/2005 The content on this page has been taken down. I want to thank those of you who voted on this topic to send the correct message to Microsoft, and those of you inside of Microsoft who took the complaints seriously and acted on them. </> – bab **Original Post This link has been making its way through the blogosphere over the past couple of days. Please take a minute and visit that link, and then come back here.

OK, folks. I’m asking you — What kinds of problems do you find hard to conquer through TDD? I’m interested in writing a continuing series on my blog about things that are difficult to create TDD. I plan on taking the suggestions that I get, both through email and as comments on this blog post, and begin solving them using C# and .Net. The intent of this series is twofold: the first result I hope to get from this is the obvious one — a set of lessons about how to TDD hard problems.

I’m glad my post on Assiduously Avoiding Setup and Teardown has engendered so much conversation over the past few weeks. I’m on vacation in Europe until August 15th, so I’ve had spotty internet connectivity. On my few opportunities to check in, however, I’ve seen a lot of activity on that post 🙂 Some of the activity concerned me, however. I really did mean what I say, and I can explain why.

Enough people have been ragging on me for not having blogged anything significant for a while that I thought I’d make use of my airplane time to say something that might actually matter (as opposed to whining about various .Net features that I don’t like :)). So here goes… Setup and Teardown Are Evil When writing tests in NUnit, JUnit, and probably most of the other xUnits around town, you have the ability to share setup and teardown logic between tests.

After many weeks and months of waiting, the Early Access Program for ReSharper 2.0 has begun. Grab it here!! For those of you who don’t know, ReSharper is a plug in for Visual Studio .Net that adds in a bunch of refactorings, navigation helpers, and other stuff that just makes you more productive. There are separate downloads for VS2003 and VS2005. Grab it, use it, and tell ‘em about it!

I’m currently scheduled to take part in a TDD webcast next Wednesday, and I’m looking for advice about what to cover. We’ve already done a basic, “This is TDD” webcast in May or so, so I’m looking for what Chapter 2 should be. Ideas I’ve had include TDD Around the Edges — how to TDD code that touches APIs, servers, databases, etc TDD and its affect on Architecture — how TDD affects the architecture of a system Whatever we do, it has to be coverable in roughly 50 minutes of talking plus demos.

What in the world do these three topics have in common??? I would have thought nothing until yesterday. But then I learned better… The Principle of Least Surprise Do me a favor, really quickly. Google “Principle of Least Surprise”. Back already? Good. It sure seems like there are a lot of folks out there who are pretty hot on using software that does what they expect it to do. And doing something unexpected, like making Ctrl-Q quit your program instead of ending macro recording, makes some folks pretty angry.

If you could design your own war room for a software team, what would be in it? I’m talking about the kind of stuff that a company can provide, not the soft stuff like candy, etc. Here are my choices: A shared, isolated space Teams need a shared space to work, but they need to be isolated from everything else. All folks involved with the project need to be welcome in the war room, but no one not on the project should be in there.

I was just reading an article in Fast Company. The theme of this issue was “Design”, and the first article in there was about designing workspaces for knowledge workers. The article was written from the point of view of the author as she was writing the article, in a shared work area, with all kinds of interruptions going on around her. Every now and then in the text, she’d add an aside about how someone just came up to her to ask a question, or she’d mention that she overheard some conversation going on a few desks over.

My group at MS is considering changing over to using the new unit testing stuff built into the newest version of Visual Studio, so I decided to give it a try. I’ll be keeping a diary of how things go today, and hopefully I’ll learn something interesting. The first thing I’ve learned is that I can’t wait for the ReSharper EAP  I need the navigation and refactoring tools I get with that.

The second part of our continuing conversation with Ron Jacobs about our time in the Delta Lounge. Scott, Peter, and I get further into team dynamics, pair programming, things that went right, and things that went wrong. Tons of fun to create, hopefully as much fun to listen to! — bab

Ron Jacobs has up Part 1 of a 2–part podcast series that Peter Provost, Scott Densmore, and I did about our working environment during Enterprise Library V1 development. I consider the fact that we were all put into the same room to be the critical success factory in letting us get Enterprise Library out the door in the time that we did, with the quality it has. Our conversations in the 2–part series roam through how and why we used the Delta Lounge, who was in there, why it was important that devs, architects, and test were all in there at the same time, how our choices in music help draw us together as a team, and more.

Cheesy title, but it caught your eye, eh? The real point of this article is to describe a TDD experience I had the other day (Friday), and how it changed my life (OK, a bit over the top, but hey,  it kept you reading…) Here is the scene. I’m working with Peter Provost and Jim Newkirk, building a Continuous Integration system to be used internally in patterns & practices. Peter and I have been the devs on it, and Jim provided the customer’s point of view.

Sometimes you accomplish nothing but you learn everything. That’s what happened to me yesterday in the Triangle Lounge. Quick background — I’m working on the Enterprise Library project in the Microsoft patterns & practices group. We’ve been working on consolidating many of the current MS Application Blocks into a single, coherent offering. We all sit in one room, called the Triangle Lounge, including the 3 remaining developers and the 3 testers.

I’ve been working on a project along with about 10 other people in a really small conference room at Microsoft in a room we’ve dubbed The Triangle Lounge. This room could comfortably fit about 5 people, but we’ve been cramming 8-10 in there every day. Why do we do it? Because we find that we are much more productive as a team if all sit in the same place.

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.

Over the years, I’ve gotten a lot of requests for non-trivial examples of code entirely written using TDD and Simple Design. I can finally give you that example. This code is for the Offline Application Block, part of Microsoft’s Smart Client initiative. Basically, it implements a framework that will allow client code to operate in much the same way, whether it is connected to the internet or not. It was written over a period of about 12 weeks, and was done entirely test first.