The need for speed

I say this a lot, but I love TDD. Besides the list of reasons about how it improves code or simplifies solutions, TDD is fast.

TDD is fun because it goes so quickly. Write a test, make it pass, refactor, run more tests.

I love the flow. I love adding a new interface and using it without worry about implementation. I love knowing after I make a new test, something in the app is different and it works. I love living in the tests and only running the application before checking in.

However, the moment the tests slow, the practices start to slip...

1. Writing code and verifying it works by launching the app, then creating the tests
   
2. Making the test pass before verifying it failed.
3. Not running all the tests before check in.
4. Not refactoring because it takes too long
5. It stops you from working close to 5 because you don't want to wait for the build
   
6. Not adding tests at all because you don't want to break the build and don't want to wait to find out
   
7. It ruins all the fun.

These things all lead to poor test coverage or tests that don't actually do what they say. Yeah, on paper your coverage may look nice, but there's plenty of code you can delete w/o breaking tests. Coverage makes sure a code path is followed, it does not verify the path was actually tested.

So, how do we keep our tests running quickly?

1. Mocking. Reduces the amount of time spent creating dependencies and their dependencies and the rabbit hole of dependencies that nobody can even see.
2. Use a one to one ratio of test assemblies to application assemblies -- don't waste time waiting for things to build that you're not testing.
   
3. Keep interfaces and implementations in separate assemblies. Dependents should only be recompiled if the contract changes, not the implementation. This allows you to complete the usage of a change, without worrying about the implementation. Sure, you can just resharper, but are you really going to add tests for a new method right now?? If you do, you break the rhythm, if you don't, you have to remember, somehow, that there is code that needs to be implemented somewhere that your tests won't pick up... you'll start thinking about the implementation or just forget and break the app without anyone knowing.
4. Simplify. Keep tests short. Only create items in setup that are used in all tests. Avoid factories for creating concrete classes because they hide dependencies and make it too easy to use real implementations instead of mocks. Avoid repeating yourself in tests, don't assert the same thing twice, it doesn't help to have the same failure twice but it does slow everything down.
   

In general, follow the best practices of test writing! They're there for a reason. No point in experiencing the pain of the nice people who figured them out. Take advantage w/o having crappy tests, lots of pain and failure.

When Agile Works

When I started consulting on an "agile" team back in February, my first thought was, "Hey! You guys lied! This isn't agile."

The working practices were reminiscent of James Shore's recent blog post.

There was Scrum but they lacked visibility, risk mitigation and self management.
There was a morning stand up, but it was a status meeting with over 20 people -- mostly watchers.
There was a single product team, but members were broken up into domain groups with their own managers, politics and definitions of success.

There were bad practices, communication breakdowns, over-commitment, over-time, half finished features, inconsistency and plenty of technical debt.

Team members had all the stress and no power to change.

But, there was hope.

Within the first few months the company reorganized and moved towards product hierarchy eliminating the contention between groups.

=>Consistent goals and priorities.

The BAs, design and product owner worked closely with an agile coach to create a product backlog. They began having sprint reviews and retrospectives.

=>Visibility and reflection.

A few people became scrum masters. A few others scrum product owners. They started going to agile conferences and local meetings.

=>Engagement.

I left at the end of July to have Kaylee. Things were changing, but we were still far from a well functioning agile team.

When I returned in November, I heard that our agile coach said this was the best agile team he's been on.

I thought to myself, "I think he's been drinking some kool-aid..."

However, when I came in for sprint review and planning, I was amazed.

So much changed.

Team members were involved.

Practice improvements and innovations were made throughout the day.

Charts and metrics were used, not shown.

People were having the right conversations.

The differences not only showed in the team and interactions, but the product.

They had visible success.

I feel very fortunate to have the unique look into the evolution of this agile team.

When you are on the team, it can seem like things don't change. Our retrospectives are a microscopic view compared to a projects lifespan. If I was working for the past 3 months, I may have not noticed.

Maybe a periodic review of how things were/how things are would be a good motivator and illustration of how cool agile can be when its working.

3 Months Later...

Almost.

Babies are challenging... Giving birth was easier... Forget about the note I was sleeping better after Kaylee was born, that didn't last long!

Ah, but the human condition. We adapt. Disrupted sleep included.

Now that I've adapted, I'm consulting again.

Apparently, I really, really like to code AND its much, much easier than being a mommy! Not quite the same ROI...

Since I do most of my work from home, I get the best of both. I'm quite lucky.

I'm with the same company and working with lots of WPF and TDD. We just started using the Isolator AAA from typemock, which looks nice. I know Roy was very involved with its creation and I usually agree with all his testing methodologies :)

My heart is still with rhinomocks, but hopefully I'll find a place for typemock too!

And being a mom, I have to include some newer pics of my lovely daughter!

My Little Wunda

I'm proud to say I'm a mom to a beautiful daughter born Saturday, August 16th. I'd like to thank my great birthing team of my husband, Vanessa (his sister) and my doula, Amy. Between them and hypnobabies, I was able to have an incredible birthing experience!

To keep up with the academic nature of this blog -- I'd like to share what I've learned so far in my few days of motherhood (note, I never picked up an infant or changed a diaper before Saturday)

1. Giving birth was the most intense, satisfying and romantic experience of my life
2. Its better to let your dog lick your infant than a person kiss their face
3. There's all kinds of great feelings for your own child you could never imagine
4. Wearing your baby is lots of fun and lets you do something while they're sleeping other than watching them sleep
5. Its still early, but so far I've been sleeping better than I have in the past few weeks (my husband however, is learning the joys of interrupted sleep)
6. Every person you talk to will give advice and everyone has different opinions on the same things (that goes for doctors, nurses, grandparents and strangers)
7. Babies like loud noises, cry before they go to the bathroom, fart louder than you could imagine and produce incredible amounts of poop!
8. If all you do is breastfeed, change diapers and sooth an infant, it can take you days to write a single email
9. In a single day, your entire outlook, appreciation and viewpoint changes completely
10. Every coo, cry, movement, poop and breath from your infant is precious

Although I'm sure I'll have my hands full, hopefully, I'll get to write some of the posts I had been putting off for the last few months while I'm away from work -- I've had a lot of adventures in WPF and TDD I'd love to share!

TechEd Pair Programing Session Overview

Since the session environment was different from our usual, and the audience's agile experience varied greatly (mostly none or little) we decided to allow the audience to ask questions during the presentation. The most successful pairing environments leverage a strong agile environment, so much of our content relies on certain knowledge of other agile practices.

Since we didn't limit questions we ended up covering the first 5 slides and lots of questions in the first 45 minutes of the class.

Not exactly the definition of a breakout session.

This made some people very happy and some people, well, not.

If you enjoyed the session, I'm really happy it helped! I hope you gained some insight you can take back to your team and good luck!

If you didn't, I hope you left early and gained interesting knowledge elsewhere you could take that back to your team and also, good luck :)

Joe White has posted a great summary of everything covered -- thanks Joe!

Most of the questions we answered would have been covered during the lecture, so if you are worried you missed out on some important information, no worries, you just got it in a different order.

Followup to Testing with Mocks

Thanks to everyone who came to the Testing with Mocks TLC session at TechEd.

Here are some links of things we touched on during the class. Please leave a comment if I missed something :)

Test Smells:
TDD Anti Patterns -- Be sure to read the comments, there are some valuable smells there too!

Books:
The Art of Unit Testing
Working Effectively with Legacy Code
TDD by Example (Kent Beck's book)

Rhino Mocks:
Ayende (creator of rhino mocks)
Google Group
Reference Guide

Other .NET Testing Frameworks:
nMock
TypeMock
Moq

Test Runners:
nUnit
mbUnit

Tools:
Resharper
TeamCity
CruiseControl.NET
CruiseControl.rb

IoC Containers:
Castle MicroKernel/Windsor
Spring.Net
StructureMap

Community:
Alt.Net

I feel like I'm taking crazy pills..

Today, I was trying out a wpf grid control and couldn't figure out how to style or data bind or do anything with it in xaml.

I sent the sales rep an email asking for some examples and I was told data binding, templates and styles were not currently supported (dependency properties it seemed too).

With that, I thanked them for their time, and said databinding and styling were a priority so we could not consider their grid.

I didn't expect to hear much after that, but I was informed that those "bells and whistles" were not as important as the other features only their grid supports...

While I would argue these "extras" are a foundation of WPF, I don't think that should matter.

Why are my priorities not valuable?

When listening to user feedback on our applications and products, we can get defensive.

We're all human and insecure, so I guess that could explain it.

However, I would rather focus on a different issue -- what is guiding our decisions, priorities and emotional responses?

Why is the response to user feedback a reason instead of thank you?

All feedback is an opportunity to create a better product. It is great service your users provide (usually for free!).

One of the greatest technical challenges in Ript was adding the ability to rip Flash. It took many, many spikes. I think most other companies would have put it aside -- it didn't add much value, wasn't going to make us money, isn't something that will make a person use the application and certainly cost time and money.

So, why did Gerry make it a requirement?

During user testing, we noticed people thought they were doing something wrong when they couldn't rip flash. They don't understand that some images are flash and some are images.

Gerry could have said document how to determine if an image is Flash so users will know why they can't do something.

But, she understood that it didn't matter if the behavior was documented. If a person thinks its broken, begins to lose trust or feels they are doing something wrong, they are alienated. They will not feel confidence in themselves or the usefulness of the program.

Before working with Gerry I didn't understand this concept. I would have put flash aside. However, her decision is what made her a great product owner.

Where I'm going, where I've been

I'll start with the where I've been:

After NBC took over Oxygen, our lovely, little agile group got a bit... lost. We lost our product owners and inspiration and little by little, we found other opportunities and now, there is no more group.

Next, I went on to an agile coaching role. While bad experiences can inspire the best writing, this was not the case. I decided to resign quickly.

That leads me to my next bit of news -- I am 20 weeks pregnant. I want to spend every week before embarking on motherhood on a worthwhile and fun adventure!

So, where am I now?

I am consulting in NYC on a motivated and talented team working on WPF applications. Its great to be back in this space!

Where am I going?

No idea. From what I hear, into sleepless nights! I plan on working after the baby, but nothing is official at the moment and I'm happy that way.

What about the hot agilistas?

No worries! Oksana and I will still be at TechEd in June. Pregnant women are hot too! Seriously, 7 months pregnant in June in Florida! Who plans that?

Painless CI?

I recently started a new project and had the fun task of getting the build server up and running. Usually, I dislike the entire process -- creating a nant script, configuring cruisecontrol... so much xml... so little fun!

Since its a new project, first order of business -- rake for builds! Something we experimented with at Oxygen, but didn't add to our practice. If you have the options of putting ruby on your build server, switch to rake if you are not already using it. Its easy to read, easy to build projects and you can reuse code. Such a nice change from the copy and paste nightmare of nant.

After spending 1/2 a day working on cruisecontrol.net and trying to figure out what configuration I needed, I realized -- hey, you can use cruisecontrol.rb -- ruby is already on the build server and we're using rake.

I'd post directions on the extra steps or setup I needed to do, but the directions from the cruisecontrol.rb site left me with a working build -- imagine that?

Tech Ed 2008

Oksana and I will be speaking about pair programming and using mock objects at Tech Ed 2008.

Register for Tech Ed here

The conference is in Orlando in June, so bring your bathing suits!

Gerry Laybourne on agile

From an interview with Gerry (page 6, scroll about halfway down the page):

"...And through that, I really got to know them and decided that I really wanted to understand agile management—which is a very interesting way of managing. It's a very formal discipline that allows the team to own the work. And what happens in software development is that you can give an assignment to a software-development team, and then six months later, they deliver what the assignment was. And you look at it and say, "Oh no, that's not what I wanted." In agile management, you work on a two-week cycle. You're working. You have a "scrum master." You have priorities set. You agree on what the priorities are in the meeting. You review the priorities. You evaluate where you are, and you move to the next step..."

I love that she knows agile is a "very formal discipline."

Because laughter is good for you..

Human tetris anyone?

Nothin but WPF

As you may have read on Boodhoo's blog -- in addition to Nothin but .NET bootcamp, he's introducing several new topics including Nothin but WPF, which I am teaching.

The first Nothin but WPF will be March 24th - 28th in midtown NYC. This class is completely focused on WPF and XAML and will include DataBinding, Styles and Resources, Custom Controls and plenty of other topics to keep us busy :)

You can register for the class here

Go here to see the current Boodhoo training schedule for 2008 -- he'll be adding more classes and an rss feed so check back for updates.