Working with Turnstile Counts
I spent may years working for a major theme park. I actually worked at the company for 5 years before joining the I.T. team as a junior developer and hardware assistant. As an assistant, I worked with Doug (the technical lead) on automating the attraction turnstiles. Prior to automation, turnstile counts were collected on the device (usually a mechanical turnstile with an LCD screen), and the employees working at the location were responsible for writing down the counts from the LCD screen every hour. Then they would manually enter the counts into a tracking system.
The automated turnstiles were network-connected and sent their counts to a server every 15 minutes. This was great for the people working at the location because they no longer had to do the manual recording process. On top of that, we could automatically transfer the counts to the tracking system.
But there was a problem: the early versions of the network modules were a little flaky and would go off-line. None of the data would be lost, but the network module would need to be reset to send the data to the server.
One of my jobs was to check the turnstile controllers every morning. This involved running some SQL scripts against the database and looking for "gaps" in the data. If a particular controller had not reported data for a while, I knew that the controller needed to be reset.
Lazy Programmer - Productive Developer
As we converted more and more attractions, this process became a bit more tedious. When there are just a few controllers to look for, the gaps were very obvious. But when there are several dozen controllers, the gaps in the data are harder to find.
I'm a lazy programmer, and so I did what any lazy programmer would do when faced with a repetitive task: automate it.Okay, so I didn't go full automation. But what I did was put together a simple application. It just had a drop-down box and a data grid.
The drop-down box had a list of all of the turnstile controllers. When a controller was selected, the grid would show the data for that one controller (with the most recent record on top). This made the job of checking the controllers very easy: I could just scroll through the drop-down box and look to see which items did not have current data.
The Application Escapes
One day I was reviewing the data with one of the managers from the area. When she saw my little helper application, she said, "Hey, what's that?"
I demoed the application and showed the raw data that came from the turnstile controllers. And she said, "Can I get that?"
The reason for this was simple: the manager had access to the tracking system which gave data that was one day old (yesterday's data). The little application that I had provided current data (well from the latest 15 minute data block, anyway). The manager really liked the idea of being able to access the data throughout the day. This way, it could be acted upon immediately.
For example, if the counts were zero, that may indicate that that the attraction was down (maybe due to a mechanical fault). If the counts were lower than expected, it could indicate that there is a staffing problem at the location that lowered the throughput. For either of these situations, the manager may want to go to the location to check what's going on.
So, I cleaned up the application a bit. I parsed the raw data into columns that the operations folks could easily understand. And I also added some total columns (for example, if there were 3 turnstiles at a location, they came through as separate records, but the operations folks were more interested in the total counts for the location. Another example, the counts came in 15 minute intervals, but they wanted to see hourly totals since that's what their operational metrics were based on).
Soon, there was an application that I had originally built for myself that was now being used by about 50 people to help them do their jobs better.
More Functionality
After the conversion from manual turnstiles to automated turnstiles was complete, this application now had all of the raw data for the locations. The managers and leads could check the data throughout the day.
As expected, the operations folks came up with some new ideas for the data. First was the idea of notifications.
At regular intervals throughout the day, they wanted to receive email or pages that had the current data. This meant that people working in the area (and not at a computer) could still take advantage of the data.
This wasn't difficult for us. We already had a notification system that could send out email or pages to different groups and individuals (we had lots of Blackberrys and Motorola pagers in use at the time). In fact, the biggest part of adding this task was to build some maintenance screens. Each person could choose which data they wanted (they could select just a few attractions or all of them) as well as the times they wanted to be notified (for example, every hour during normal operating hours) as well as the days of the week to be notified (so they would only get the information on days they were working).
This added about 50 more people who could access the data on a regular basis to help them keep the business functioning efficiently.
Yet Another Feature
The next step was to add "alerts". For each location, they could enter a target number and a warning threshold. For each page, we would include the current count plus the target number for reference. And if the current count fell below the warning threshold, that would trigger a separate set of "alert" pages.
And Another
The last major feature that we added was a summary email that was sent out every morning. This would include a summary of the prior day's data so that directors and area managers could track how things were going. This replaced a manual process that the attractions staff was doing.
Now the leadership team was able to directly benefit from the data collected.
Organically Grown
Now this isn't a process that happened overnight. These features grew over a period of several years. But the interesting thing about this is that it was not a set of features that was originally requested by the business area. It was something that I built for my own use that happened to have usefulness beyond just me.
And I think that's why I have such an affection for this particular application. This wasn't a "project" that the business area came up with. When the turnstiles were being automated, the primary benefit was to eliminate the labor spent collecting the counts manually (and the potential for transcription error) and putting the data into the tracking system (with potential for more errors).
No one asked for a system that would page (near) real-time numbers to the operating areas. But once we had the data, and the users in the business area started to see the how they could benefit from it, things just grew naturally.
We discovered value incrementally over time. And the end result had a lot more benefit than anyone had anticipated.
Wrap Up
So, this brings us back to the idea of "No Estimates". It's not just that we are bad at estimating features that are asked for by the business area. It's that we don't even know where the real value lies when we start out on a project.
This really shouldn't be a surprise. One of the major tenets of Agile is that we adjust our direction when we need to. When we see potential value, we're allowed to shift our current direction to pursue that. And these feature requests came in small chunks. At the beginning, I never would have been able to put together a viable estimate/plan for "send out current turnstile counts to selected individuals". But because we took things one step at a time (raw data, formatted data, summarized data, notifications), we were able to get to this unexpected result that added value to the company.
I guess I'm convincing myself more and more that I like the idea of No Estimates. When I look at projects that added real value to the company (like this one), it seems like we pretty much worked that way. (There was some project overhead, but minimal compared to most of the applications we worked on.)
I've got a couple more stories like this one that I'll be sharing soon. In the meantime, keep thinking about ways that you can be an effective developer and add the most value to the company.
Happy Coding!
No comments:
Post a Comment