Monday, October 29, 2012

2012 MLB Dollars Per Win

With the San Francisco Giants' sweep of the Detroit Tigers last night, the 2012 MLB Season is officially in the books.

As I've done the past few years, I broke things down in simple terms: which teams were the most efficient in getting the most value per dollar in payroll? Yes, this isn't really a straightforward answer, since teams with higher payrolls tend to have higher non-baseball revenues (namely merchandising and TV deals), but from a pure baseball standpoint: who had the best year?

Below is a simple table of how teams ended up in terms of dollars in payroll vs. total wins (including post-season). The Oakland Athletics, a perennially efficient team, did extremely well this year, spending nearly one fifth as much per win as the lowly Red Sox. Not to be forgotten was the sub-par performance of the Phillies this season.

Source for payroll amounts:

The World Series Champion San Francisco Giants ended up in the middle of the pack due to their above average payroll, though one could argue winning it all is worth it. I would also credit the Washington Nationals for being the only other 100 win team while having a below average payroll; great year for the Natinals.

Just for your edification, here is the correlation between wins and payroll this year. Note how low R^2 is: 0.053. I'd have to look at other years, but this year turned out to be quite a year of parity.

Saturday, October 20, 2012

Nissan's New "Steer By Wire" Technology

Before watching the video, I wasn't sure what Nissan was trying to accomplish. I didn't know of any market demand for this technology. After viewing the video and learning of the "smooth ride" capabilities, I was hooked. I can't wait for this to arrive in all cars.

I'm assuming the clutch also serves as the mechanical back-up in the event of a loss of power to the control units; the video seems to state that. That would be a major concern from a safety standpoint.

This also plays right into my dream of driverless cars. With this new system, all you'd need to do to make the vehicle driverless (assuming you completely remove the human driver) is ditch the steering wheel and clutch and plug the control unit into a master vehicle controller, which would also control throttle and brake. No more goofy actuators on the steering wheel; full-authority steering! 

Monday, October 8, 2012

Pizza Delivery Routing Algorithm - A Pet Project

A couple months ago I realized that I had completely given up on my interest in web application development. I'd studied it briefly towards the end of my Master's curriculum a couple years ago, and had been meaning to reignite my interest through a couple projects. I'm not very gifted at web development, but I've seen enough to become interested. Alas, starting an MBA and getting married became greater (and worthwhile) time sinks.

The good news (for me and my interest) is that my wedding is on Saturday, which means I'll have some free time coming up. That, and I'm most of the way through the core MBA curriculum. Right now I'm taking a course in information systems management, which, if anything, is feeding my interest in restarting my hobby. My buddy Sam has been working on something for a couple years now, and his advice was simple: "Just do something, anything. Keep sharp."

My first project: pizza delivery routing algorithm. As I've mentioned before here, I used to deliver pizzas in high school and during college breaks. I developed a strange passion for operational efficiency after the business expanded and we had a new Point of Sale (POS) system installed. This was in 2004. My boss had no interest in even developing a website for the business at the time. He was mostly concerned with building the business one week at a time. But that didn't stop me from analyzing how inefficient some of our processes were - I was an engineering student, after all.

One of the major annoyances in operating a business with a personal delivery component (e.g. pizza) is figuring out how best to allocate your delivery resources (e.g. the drivers). My boss was notorious for taking guys off the clock if business was slow. The drivers figured this out quickly and gamed the system by taking as long as reasonably possible to complete a delivery during the slow down periods. It infuriated the boss, but he had to live with it.

On the flip side, when business was booming (e.g. during the dinner rush on a Friday night), we couldn't have enough drivers. Orders would run late because of the sheer backlog. Guys would make 2-3 trips per hour. Even with 15 drivers on the clock at once, we couldn't keep up. Drivers were motivated mostly by tips, and knew that getting the order to the customer sooner rather than later would result in a better tip. Drivers couldn't care less if the next order was late. This led to serious inefficiency. Whenever I was in charge of routing deliveries, I'd have guys wait a few agonizing minutes for any deliveries they could take in tandem based on geographical proximity - basically: if you have two orders going to Main Street in Trumbull (a 15 minute drive), have the driver take both even if they came in 10 minutes apart. It drove drivers, and my boss, crazy, but it resulted in fewer late orders on the whole. We would call these "two baggers" or "three baggers" - depending on how many orders went out (in warming bags).

I wished that the manual routing I had to do were somehow automated. I know there has to be something already out there now, but I figured my first project would be to develop something simple.

The interface should be straightforward: provide the user (e.g. manager) with a table of all open delivery orders grouped by recommended batch. A batch would be determined based on driving time for the round trip and would be temporal - you wouldn't batch two orders together that were ordered more than 35 minutes apart (for argument's sake). The idea is to provide the manager with a set of options to maximize the efficiency of each delivery driver at any one time.

The system would have to be flexible and optional. It would have to interface with the existing POS system to collect all open orders coming in. It should be optional because of various factors that come into play, especially driver skill. A manager probably wouldn't want to assign a long and expensive "three bagger" to the newest driver. The manager would have the option to break the orders into pieces. Therefore, the system would have the be "slave" to the POS system except, perhaps, if the manager decided to go with the recommendation and assign deliveries through it and have the POS system only become the "slave" in such cases. For example, if the system recommends a particular batch, the manager would select that batch, match it with a driver, and click "ASSIGN." The system would send the request to the POS system, which would assign those three orders to the driver.

I plan on using the MapQuest API for the background routing algorithm. There are many other options, but I found MapQuest's to be the most open for now.

There are a few tricky aspects that I'll need to take into account:

- Ensuring the correct address is entered. This would probably need to be tied in with the POS - the user may need to confirm the address with the customer.
- Tweaking the interface with the POS system to pull and push requests (timing, etc.). I'll have to make my own dummy POS for starters.
- Tweaking the algorithm to take other factors into account, like weather (doubtful) and performance parameters for drivers like average delivery time (maybe)

I doubt any business would actually pay for this, but it's a neat project. Maybe, just maybe, I could get a blurb in Pizza Today.

Tuesday, October 2, 2012

The CN Turbo Train

Canadian rail was way ahead of its time.

The TurboTrain - a United Aircraft product.