att Mannion is an Engagement Manager for Clarity Consulting Inc., a Chicago-based technology consulting firm and Microsoft Gold Certified Partner. Matt has delivered many large-scale, WinForm and WebForm systems for a variety of industries, including retail, financial services, publishing, and banking. Contact Matt at email@example.com
So let's introduce this whole thing. What is it all about?
Matt Mannion: Well, the IRL, or Indy Racing League, had an application in place that they provided for the teams in the pitsthe pit crews, the media, as well as manufacturers and race officials themselves. It was a Java Flash application that they wrote quite a while ago; and it worked okay for them, but it didn't give the users all of the flexibility and functionality that they were looking for. It was not customizable. The view you got of the race results was what you had to stick with, change columns or highlight particular cars or racers, or hone in on different metrics within the application. And it wasn't scaling well, as they needed to put more users up on it, and it just wasn't scaling well.
Carl Franklin: And you guys came in, and the rest is history. Now, so what did you guys do for them?
Matt Mannion: They brought us in to build, actually, a new application to provide results to the teams and the media. So our job was to come in and build an application that would give them the additional functionality and scalability that they were looking for.
Carl Franklin: Oh, great. Now, when you say it was a "Flash Java application," you mean Java on the back-end and Flash on the front-end with some sort of the Flash language, the action script or whatever?
Matt Mannion: Correct, yeah. The presentation layer was done in Flash, and the developer who did it was actually a Flash developer; so he just kind of migrated to that tool to build this application. It really wasn't a very good fit. That type of Web application wasn't a good fit for Flash. It was very tedious to build and very time-consuming and costly to maintain and to modify. So as a result, they just never modified it. They weren't able to make changes and provide the functionality to the users that they needed.
Carl Franklin: When you say, it was "tedious to build", it is kind of like a contradiction in terms, because the whole reason you would use Flash is the ease of use in which you can create something working that looks pretty good in a very small package very quickly. And so it is interesting to hear you say that it was sort of tedious. Richard, have you ever used Flash?
Richard Campbell: No, I am not a big Flash follower; but I have certainly worked in projects around those things.
Now, I can imagine why you would say it was tedious. You know, Flash is good at some things; it is not good at others. When you talk about, like, meticulously detailed forms and those kinds of things, I do not see Flash as a great tool for that. It is great for creating something a little more amorphous; but the feature sets got to be pretty simple to really make Flash make sense.
Carl Franklin: And what were some of the brick walls that you run up against UI-wise, or that they ran up against?
Matt Mannion: Well, the main result here is a DataGrid, and it presents one row in a grid per car that's on the track; and then there's, like I said before, 30 or 40 different metrics, or measurements, that this system is taking as the car goes around the track, like lap speed, average lap speed, last lap speed, and all that stuff. And so they had to build this matrix, this gird, in Flash and, as you pointed out, that type of application just doesn't play well with Flash. So I actually got a look at some of the code that this guy had to sling to make this work, and it just wasn't pretty.
Richard Campbell: When you think about all the stuff that's actually in a grid, just the grid lines alone, every bit of that has to be coded in Flash.
Carl Franklin: Now just back us up a little bit and tell us what exactly the kinds of things this program does. This is for taking measurements and displaying those things to the pit crew and the user and basically keeping everybody informed with the stats of what's going on in the race? Is that what it's all about?
Matt Mannion: Yeah. The way it works is the track is actually outfitted with five or six pick-up points around the track. Each track that the IRL runs a race on has been outfitted with these data sensors around the track. And each car has mounted underneath it at a specified point from the nose has to be the exact same distance for each car. It's like 33 inches from the nose. You have to mount this transponder underneath the car. And then as the car goes around the track and the transponder goes over these pick-ups that are channeled in the track, it sends information back to a central computer. It is capturing that information, and it knows the time it takes to get from one pick-up point to the next. It can calculate the speed.
Carl Franklin: So it calculates speed, velocity, and all that other kind of stuff?
Matt Mannion: Correct. So through the course of an average race, this system is collecting 80,000 to 100,000 data points.
Carl Franklin: Wow!
Richard Campbell: That is a lot of data.
Carl Franklin: And about how many cars race in one race?
Matt Mannion: There are between 30 and 35 on the track at any given time.
Carl Franklin: Okay.
Matt Mannion: Yeah. I started to say that all that data then gets sent back to a SQL 2000 database, and then from there it was our job to present that data to the users in a way that could be useful and helpful for them.
And everybody is looking at it from a different perspective. The race teams are looking at how fast the car is running; maybe at a certain section, certain turns, they are looking at lap speeds, average lap speed and things like that. The manufacturers are looking at something different, and then the media and the race officials are all looking at something different. So the application needed to be highly customizable, so everybody could look at or hone in on different pieces of data that they'd want to see at any given time.
Richard Campbell: So you've got this one source of all this information. You've got to be able to put it out in lots of different ways.
Matt Mannion: Correct.
Carl Franklin: I just want to give everybody the URL to the case study that Microsoft did on the Indy Racing League Project. It's at http://shrinkster.com/4r2; and in that, you can get a really good sense of what the application is and what it does, if you are not getting it from this interview (laughs). But there is a lot more information out there in terms of the reasons why they chose .NET.
You know, one thing I thought was really interesting reading this case study is the constraints that you guys were under to provide this application. Tell me how that came to be, that all of a sudden you had X amount of weeks and it absolutely had to be done quickly, and tell me about that.
Matt Mannion: Yeah. It was kind of painful, and I don't know all the circumstances that led up to the shortened time frame. But by the time we were brought in by the IRL to help them build this, it was Decemberactually, I think it was maybe late Novemberand they needed it by January, because they knew that their first race or their first practice run was going to be in Florida in January.
Richard Campbell: Ouch.
Matt Mannion: We eventually had a five-week window and a very tight and limited budget to deliver this application, so it was pretty hectic. But that was a big part of why they brought us in and why we chose the .NET platform to help us get that done.
Carl Franklin: And so they were basically just like, "Help!" and you guys decided that you would use .NET. You obviously had been using it before and having some success. What was your particular role in the project?
Matt Mannion: My role was Engagement Manager and, actually, I turned out to be the Lead Developer as well because there was myself, a partner from Clarity, and then we had one developer from the IRL working on it. So it was threeor, really, two-and-a-half resources on the project for the five-week period.
Richard Campbell: Three people and five weeks to build the whole thing.
Carl Franklin: And what were the different pieces that were involved?
Matt Mannion: The main application is obviously the result viewer. That's what everybody is using and looking at. But on top of that, then we also had an operator console, which is what they used to set up each race, all the practice sessions. A race really consists of, like, a three- or four-day event, and there are usually two practice sessions, a qualifying session and then the race, which is at the end of the last part of the event.
So the operator console allows them to define the race, all the practice sessions they are going to have, the start and stop time of each session, and all that is visible on the viewer.
We had the operator console, the results viewer and then we also provided a way to look at historical results that they could take home with them at the end of the race. So there was a viewer for that, as well.
Carl Franklin: Cool.
Richard Campbell: So you could actually dump some data, be disconnected from the central server, and still view their race data.
Matt Mannion: Absolutely, yeah, because the data grid that we used to show the results was actually driven by a strongly typed data set that we just bound to that data grid.
Over that, we were given the option to just persist that data set to an XML data set on the local hard drive. And then when they leave, they can go home, and they can analyze those race results at their leisure disconnected. And over time, we would build up so at the end year these 12 or 14 or 16 races, we'd have a data set for each one. They can actually compare performances from each race.
Richard Campbell: Excellent.