Mental Pandiculation

Tim Bray writes about when and how he does TDD. I think he’s exactly right when he talks about not doing TDD for green-field, beginning development. When I’m first writing a cut at a new project, I’ve got almost no idea what I’m doing. Doing TDD at this stage in the game is super expensive and really gets in the way of the exploration necessary for a new project. Having to rewrite my code as it evolves is expected but having to rewrite my code AND my tests because both were completely off base is pretty inefficient.

However, once things are pointed in the right direction, TDD is critical. It makes the incremental evolution of the software much safer, easier and efficient. Without the tests, iterating over your software is painful and liable to introduce bugs in code that was once working. TDD is at its best in the situation where the code, while not stable, is in a state of incremental evolution and not the general state of random upheaval that it is in the beginning of the project.

Like most things, pragmatism is useful. There are shades of gray around everything and saying that there is one true way makes no sense at all. TDD is useful as a tool but hammering every nail you see with it probably isn’t the best way to do things.

I’ve also started to see TDD as a tool to allow those of us who aren’t geniuses to actually produce good code. I’ve known a few true code geniuses in my career and like Picasso, their art tends to spring fully formed out of their heads. They may go back later and write tests around the code. However, they don’t need TDD to be good. For the rest of us, the incremental evolution that TDD supports and encourages helps us to write code that is functional and clean because we have to focus on the client of our software. Those of us who aren’t masters use TDD to fake it, to produce works of art that might not eventually hang on the walls of the Louvre but that make customers at art fairs all over the world reasonably happy.

Why Perforce is more scalable than Git. I’ve always had a soft spot in my heart for Perforce. It’s an awesome tool, one that “just works” when you get to know it. I’ll admit, branching isn’t easy but I learned how to do it and I’m not that smart. I taught an entire outsourced staff of developers flown in special from India how to use it and while I honestly don’t think they understood anything I said, they did nod happily and shake my hand saying something to the effect of “Good presentation” when I was done. So Perforce must be OK.

Git strikes me as a shiny, jangly, “Oh look there’s a chicken!” bauble for ADHD-stricken developers who can’t score a Modafinil prescription. I say this with absolutely no understanding or use of Git which makes me supremely qualified to dis it on the Internet. But look, it’s nice that it’s all cool and distributed and fancy-pants-in-with-the-in-crowd but I have my doubts that you could ever stick it in a corporate environment with 10 gigs of source data and have it work very well. Not to mention trying to get the average developer’s head around how you could possibly have a distributed source control system. To which the Internet trolls say “that’s how we like it”. To which I say “yeah but here in the real world where we don’t sleep in our mom’s basement and we need source control to be, you know, boring.”

Personally I don’t see how on earth I could ever end up with a 6 gig repository. What, are you checking in an entire copy of the Vista and Visual Studio ISO’s?

If you need to have your toolchain or test data in a repository, try putting it in a separate repository. This way it doesn’t fuck up your source code repository, which is designed to store… oh I dunno, source code?

That’s a quote from reddit which is typical of your average “never worked in a corporate environment” hacker. Don’t get me wrong, I’m jealous of people who never worked in a corporate environment but that doesn’t make those of us who have idiots. As it turns out, corporate environments need different things than people hacking on the 42nd version of their Quake ripoff. In the real world, EVERYTHING gets versioned. It’s called CYA and it’s important. Trust me. It just is. And when it’s important, you need a tool that thinks it’s important too. Git just isn’t it.

There will always be new shiny things to keep those of us who need such things entertained. But in the end, tools like Perforce are meant for bigger tasks. As it turns out, they’re actually good at them.

They tell me (They who? The voices in my head singing like angels from Heaven. Ed.) that admitting you have a problem is the first step to recovery. What they don’t tell me is that it’s also the first step to becoming a full blown addict, lying in the gutter wondering if this is how Edgar Allen Poe died. I’m not sure which of those will happen but I’m addicted to StackOverflow. I have been aware of StackOverflow for quite awhile now because anytime I search for an answer to a tech question, the site pops up prominently in the results usually. However, I had resisted digging into how it worked too much, even though I listen to the weekly podcasts by Atwood and Spolsky.

All that changed last week. I’m going to the StackOverflow Dev Days in Washington, D.C. in October and it occurred to me that it would be conference suicide to not have at least signed up for the site. So, last week, I dutifully signed up, figuring nothing would ever come of it. How wrong I was.

For those of you unfamiliar with the site, it’s a place where people can post questions about any kind of programming problem and have the community answer them. While this sounds just like every other site or forum out there, the difference here is that people vote on both the answers and the questions so that the cream rises to the top. On top of that, registered users of the site have what is called reputation. Your site reputation is based on how much you participate in the community. The more questions you ask, answer or correct (among other actions), the higher reputation you have. There are also badges which are doled out based on things you do.

No longer do people answer questions out of the goodness of their black, little hearts. They start doing it so that their reputation score goes up. Better answers means more reputation. People start checking the site every day. People edit their answers so that they are better. People start checking the Unanswered list, hoping to find a really tough question to answer because it’s worth more (I think. It should be if it’s not). This is all hypothetical of course. I wouldn’t really know.

Ha, who am I kidding? It’s a sick, sick, little cycle, one that I’ve fully been sucked into. I’ve answered two questions on the site, I have 1 badge (Teacher! Woohoo!) and my reputation is up to 21 in 7 days. It really is addicting. It’s taken every ounce of self-discipline I have not to go try to answer a question while I write this post.

I have a goal of getting my reputation at least up to above 1000 before I go to the conference (if you’re interested, they just added several more days). I have no idea if that’s possible but since I haven’t seen anything about StackOverflow methadone or treatment at the Mayo clinic, I figure I have a pretty good chance.

If you are going to implement the INotifyPropertyChanged event in your ViewModel (or anywhere for that matter) so that you can bind to the property in XAML, it’s important to actually change the property before raising the PropertyChanged event. If you are crazy like I am, you’ll raise the event before you set the property and then spend 2 hours wondering why all your other properties correctly update the page but this new property does not.

Eventually, like one of those stupid pictures you have to stare at for 76 minutes before the killer whale eating the baby seal becomes apparent (What, you saw a cute puppy dog? Oh, my bad), you’ll notice that raising the event first is never going to give you the results you want. So if you are having trouble with your properties getting updated, check the order of your notification. It’s important.

That is all. We will now return to our normally scheduled programming.

I’m using the IUnityContainer from the Composite Application Guidance in my current Silverlight project for Dependency Injection and this morning, I came across something that I couldn’t find documented anywhere. Initially, all my registered dependencies were being created using other dependencies that I had registered with the container. For example, I had the CustomerOrderService below and it was created using an IEventAggregator that was already registered in the container.

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg)
        {
            this.eventAggregator = evAg;
        }
    }

I was just registering my service with the container and letting it do all the work.

this.container.RegisterType();

However, this morning, I wanted to add a simple string to my constructor so that I could pass in the URI for a web service instead of hard coding it in the service class. After digging around a little in the docs and eventually just playing with the code until it worked, I came up with two ways of doing this.

First, I modified my service to have two constructor arguments:

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg, string uri)
        {
            this.eventAggregator = evAg;
            this.baseUri = uri;
        }
    }

Then, I came up with the two ways to register this service in code with the container. First, you can tell the container how to configure your dependency registration.

this.container.Configure().ConfigureInjectionFor(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

When the container is asked to create a CustomerOrderService object, it is configured to send in an IEventAggregator instance that it resolves internally and the URI string above. Of course, in a real world app, that URI would actually be a URI that I get from configuration.

Alternatively, you can tell the container what to do when you register the type:

this.container.RegisterType(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

This is a little cleaner because you’re going to have to register the type anyway and it makes sense to configure it at the same time.

By allowing the developer to specify an InjectionConstructor to use, the UnityContainer gives the developer a much more flexible way to register his dependencies.

What would happen if midway through the the NFL season last year, the Pittsburgh Steelers, standing at 6 and 2 and leading the AFC North, had decided that their football season was over and disbanded the team? Or what if they decided to move Big Ben to the training squad because he was a prime performer and the training squad wasn’t really performing very well? What, you say? This would never happen?

No of course this would never happen for a variety of reasons not the least of which is that a team doesn’t just disband. A team doesn’t take their best performers and move them onto another project because that project is sucking wind. A team may lose a player here and there due to injury or trade or retirement but there is a sense of continuity to a team that exists above and beyond the sum of the team’s parts. A team has common, long-term goals like “winning tonight’s game”, “winning the division” and “keeping our superstars with the team”. Successful teams of all types typically have a common culture and no divas. Or at least the divas are under something resembling control. Even on NBA teams, where there are often divas of extraordinary divahood, winning rarely comes consistently unless the rest of the team buys into both the system and the superstar. Conversely, on bad teams, you may have one of the greatest players ever (see: Kevin Garnett pre-Boston Celtics) and still lose all the time.

This is true of all kinds of teams. Without some semblance of stability, culture, direction and goal, teams fail. In fact, they often implode. And yet, we in the software industry continue to call groups of people “teams” when they are at best, loosely grouped collections of individuals with similar skillsets working temporarily on a common project and at worst, highly dysfunctional trapeze artists who would like nothing better than to cut down the safety net and install 2 ounces of extra weight in the left side of their fellow coders balance bar. Project teams are not teams.

This is one of the gorillas in the room of current software methodology. We talk about software teams as if they want nothing more than to succeed when in fact, oftentimes, they could care less and may even have motives to foster failure. Of course, you could argue that we come up with methodologies to standardize these poor teams. But then someone might call you a cynic.

Granted, there are teams like this in the sports world but they don’t typically stay teams very long. They are broken up, sent away and rebuilt with the goal of having a real team. But in software, dysfunctional teams may stay together for office political reasons and completely successful teams may be disbanded in an effort to spread the success around, ignoring the fact that the team may have been successful because they were a team. We continue to treat software teams as if they are completely different from any other type of team we have ever encountered in reality.

As long as we keep trying to treat the symptoms of the disease instead of the actual disease, we’ll continue to have an industry that languishes. Stability is the critical component of the long term success of a software development team. Doing anything that undermines that stability contributes to the continued failures in software development that we keep trying to cure with a new methodology. A solid, stable, professional team can write software using any methodology. It’s only because we refuse that stability that we have to have silver bullet methodologies to try to cure so many of the symptoms of the disease.

The project I’m currently working on is a Silverlight app and I’m in the throes of converting it to use the Composite Application Guidance framework from Microsoft. It’s been a reasonably mind-bending experience but also fairly straightforward if that’s possible. However, something popped up today that warrants mentioning.

I’m using the Unity Application Block as a Dependency Injection framework, also from Microsoft. I made a couple of changes to my app and started getting “Unable to resolve dependency” exceptions for a constructor of an object. The catch was, I was definitely registering all my dependencies and they were being created correctly. Turns out, I had just added the EventAggregator portion of the framework and had subscribed one of my events to a private event handler while I wasn’t paying attention which obviously won’t work since the event handler has to be public.

The problem occurred when the MethodAccessException did not get bubbled up correctly to my Module. Instead, it’s getting swallowed somewhere down in the ModuleInitializer and the exception getting tossed out is an “Unable to resolve dependency” exception which might confuse the hell out of you if you were positive you had all your dependencies resolved. I haven’t dug deep enough yet to figure out where the original exception is getting swallowed but I figured all this out when I wrapped a try-catch around the initialization code of the object that the framework was complaining about. Change the event handler to public and woohoo, we’re back in business.

As an aside, I’ve been pretty happy with the Composite Application Guidance framework. It’s a BIG chunk of functionality but it seems to be all things you really need in WPF and Silverlight apps. I’m hoping to have a few more posts about happier times with it soon but for now, I recommend checking it out if you’re working with WPF or Silverlight.

I ran across this presentation claiming that agile is the new waterfall, that by following some method of agile dogmatically, you are merely substituting one dogma for another and you have failed to gain any learning or understanding. While this may very well be true in certain cases, it reminds me of the opening line to Anna Karenina: All happy families are alike. Every unhappy family is unhappy in its own way. Many people say that you should take the pieces of agile that work for you, use them and discard the rest. If you’re dealing with a team that is already functional, this works. Teams that are already highly functional can take any process piecemeal and work it out because they are already functional. Teams that are dysfunctional are dysfunctional in hundreds of different ways and allowing these teams to choose what parts of any methodology they implement leads them to reinforce their dysfunctions instead of fixing them.

For teams that are highly dysfunctional, picking and choosing pieces of any methodology will undoubtedly result in failure, not because they chose pieces of waterfall or pieces of Six Sigma or pieces of agile. It will fail because they are already dysfunctional and the best way a methodology can help dysfunctional teams is by applying the entire methodology, sorting out later what pieces do and do not work once understanding has been achieved. We, as proponents of whatever methodology we prefer, do these teams a disservice when we allow them believe that doing pieces that “fit” will lead them to greater function.

Dogmas aren’t created to immediately impart understanding. That only comes wisdom and experience. Music students play all scales over and over, dogmatically. They do that because eventually, that dogmatic approach will lead to higher understanding about their craft. If a music student looks at scales and says “I’m only going to play the C Scale”, they will never gain the ability to understand how knowing all scales makes them a better player. The student must play all scales to gain the most benefit and understanding. In fact, music students should play their weakest scales more in order to improve more. In the same way, I believe applying any methodology in whole to dysfunctional teams has the potential to do the same thing, more quickly than doing it piecemeal.

Methodologies aren’t designed for functional teams. They don’t NEED them. Methodologies are designed for dysfunctional teams, ones that need help not because of their methodology but because of underlying issues with the team or the environment. Taking the pieces “that work for you” from any process results in only focusing on your strengths and avoiding your weaknesses. Do that will never lead to success will never lead to a stronger team, only a more unbalanced team.

If you’re working in Silverlight and your app suddenly starts giving you the white screen of death, chances are there’s something wrong with the markup. Of course, since the white screen of death results in zero exceptions, sometimes it’s hard to track down what the problem is. Enter the Error Console in Firefox. If you get a WSOD, pop open Tools->Error Console in Firefox, scroll to the bottom of the list and you might be pleasantly surprised to find your problem described there.

If you have an ItemsControl that is throwing an exception telling you the collection is read-only when you call Clear() on the Items property before resetting the data binding, try setting the ItemsSource property to null instead.