In episode #109 Matt Mannion from Clarity Consulting talks about the application his company developed with and for the Indy Racing League in Indianapolis, IN. Using Visual Studio .NET 2003 and VB.NET they were able to develop a great application for managing real-time racing data and reporting.

Matt 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 mannion@claritycon.com.

Carl Franklin: 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 pits -- the 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 data grid, 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 December -- actually, I think it was maybe late November -- and 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 three -- or, 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.

Carl Franklin: That's interesting. Now, the operator console, is this a Windows' application or a Web app or what?

Matt Mannion: That's a WinForms app, as well. It's only got one user, basically. It's the folks in the timing and scoring booth.

Carl Franklin: And were you guys writing directly with ADO.NET just to SQL server over TCP/IP, or you were using Web services, or what did the transport look like?

Matt Mannion: No, we didn't use a Web service. We just basically were using ADO.NET.

Carl Franklin: Okay. And how much was that SQL server working? How did it perform?

Matt Mannion: The SQL server performed outstanding. It was powered on a pretty nice-sized server; but it's pretty taxing, because while the one application is shooting in these 80,000 to 100,000 rows, we have got anywhere from 40 or 50-plus users hitting this thing with about a half-second refresh rate to get the latest results back. So the results on the screen are never more than a half-second old. So in the timing, it was actually pretty quick from the track from the transponder to the SQL and then back up to the viewer.

Richard Campbell: I was just thinking, you must have another glob of code sitting there monitoring the transponder and, as data is coming in, writing it to the database. And then you're just straight polling against the database to see the data as it comes in.

Matt Mannion: Right. Those were two disconnected processes; and there was one application that was running, just collecting it off the track and shooting it into the SQL server, and then there was our application sitting on top of the SQL server, just pulling data off every half-second for each client.

Richard Campbell: So the main thing you guys worked on was the presentation side of this. The feed stuff worked?

Matt Mannion: Correct. The infrastructure for the data feed off the track, and the transponders were already in place.

Richard Campbell: That's nice.

Carl Franklin: I like this quote from Jon Koskey. It says initially, he was concerned that the increased volume of aggregate data could be an issue in the server's performance. "In a typical race, we will feed 80,000 to 100,000 records into the database, in addition to a lot of outgoing information. We are serving up 300 to 600 simultaneous connections per second." he says. "We were a little worried about how SQL Server would handle that volume; but as it turns out, we were running at less than 20% of processing power." That's awesome.

Matt Mannion: Yeah, and we tested that back in Indianapolis when we were building the application. What I did was, I used an application-center test act, and basically, we just put up a Web page that was just calling in to that results viewer's method and stored proc. And I just loaded up several hundred clients just hammering away on that thing, and I put performance monitors up on the SQL Server box and tuned the query that way and just let it fly. And before we even got out to the track, we knew that that thing was going to perform real well.

Richard Campbell: This is a Smart Client app, right? This is not a Web-based app.

Matt Mannion: It's not Web-based. It's Windows' form application; and it was a Smart Client application, because they really wanted the ability to push updates out to the teams without having to disrupt them or visit each team and station and install an update.

Richard Campbell: Yeah. I guess all these teams are independent entities, they've got their own gear, and you need to work with what they've got.

Matt Mannion: Correct. We publish minimum standards that they need to have in order to run the application, and after that, they just show up with whatever they want. And as you pointed out, it could be a Tablet PC, it could be a Desktop or whatever.

And then there are so many different players they are dealing with, because beyond the crew, then they have the media. They are all looking at this, so they are running it. The manufacturers come in, and they want to see how their tires and motors and what-have-you are performing out on the track so they come in and they want to look at results, so they are looking at it. So a lot of times, you don't even know who is coming in on each race. So it was very difficult to coordinate those updates.

Richard Campbell: All these different bits of data about specs on the car, state of the tires and all those kinds of things are coming regularly via the sensors on the track.

Matt Mannion: Right. Well, the performance of the car is coming through the track, and then they can interpret what that means.

Carl Franklin: Yeah. I was going to say, some of the data gets inferred from just the raw data and the ratios.

Richard Campbell: Yeah, because I know I have read lots about racecars having telemetry systems; but I wasn't sure that the track data was part of that same telemetry, or if they are separate things.

Matt Mannion: A lot of times, it's separate. The car owners themselves might put monitoring systems and sensors in their cars themselves. They are only privy to that.

Richard Campbell: So then, they have detailed data of their car; but when it comes to official track-performance figures, the track is in control of that.

Matt Mannion: Correct. The results that come out of the system are the official results published by the IRL.

Richard Campbell: And everybody is using wireless for it. I am just wondering how well the wireless network held up under all those machines and all those connections?

Matt Mannion: You know what? When we were out at Phoenix, surprisingly, there was one little glitch at one end of the track that just on the way down -- you know how the figure runs all the way down the straightaway there? Folks on the far ends were having a difficulty; but they actually were able to remedy that. And for the most part, it runs real well.

Richard Campbell: Wow! So, I mean, a bunch of access points, or just one really powerful antenna?

Matt Mannion: They actually had one other relay point on the track at the race I was at.

Carl Franklin: I've got a really interesting question, and I don't know if you can specifically address this yourself. But do you remember? What were some of the specific problems they were having with the Flash Java version that were solved or are non-issues in the .NET version that you wrote?

Matt Mannion: Well, there were issues on both ends of it. There were issues from the developer perspective that we already talked about, just the difficulty in maintaining it. And given the way the race season runs most of the year, they have very little time to be back in the office and modifying their applications, where they are back out on the road and doing a race every month? So they really don't have a big window in which to do these application changes.

Carl Franklin: I also read in the case study that there were some problems with the different versions of the JRE caching on the client or on the server or something? There were some issues with versioning that couldn't be solved.

Matt Mannion: Yeah, they ran into some issues with that; and they had issues with, like, a middle tier that actually sat between their SQL server and the Flash application, and they had issues with that, as well.

And then the other problem they had was, they just couldn't customize it. So like I said, there were, like, 40 or 50 data points that you can look at; and with the Flash application, you had to look at all of them.

Carl Franklin: You know, Richard, as I am reading the case study and listening to the story, I get the distinct feeling that this is, like, the perfect application to write. It's not mired in lots of complex business objects and lots of rules and extremely large, complex architectures. It's a simple, data set-centric ADO.NET app.

Richard Campbell: But it's velocity-sensitive. I mean, the timeliness of the data is critical. And it's got to be very customizable. There is more data than you can possibly, reasonably look at; so you need to be able to sort it in the form you need to see that.

Carl Franklin: But I guess what I am saying is, it seems like it is made for that model. Like, the whole .NET data set-centric programming model really just is, like, a no-brainer in this situation.

Richard Campbell: Well, and the kicker is the offline stuff.

Carl Franklin: Oh, yeah, totally. That's great. It's the kind of application that I wish I could get to write once in a while, you know.

(Laughter)

Matt Mannion: It was a real fun application to write, because as we were building this, we had a simulator there in the office that would run with a videotape of historical races; and as the video was running, in the background, we can simulate the data coming through for those cars. So it was just fun to do. The only thing was just the time frame within which we had to do it.

But other than that, you're right. It was just a classic WinForm app: dataset, bind to a grid. The thing that made it difficult was all the functionality they wanted in the grid.

Richard Campbell: In five weeks.