More Organic Software: Escaping Into the Wild

A couple days ago, I wrote about how an application I wrote for myself escaped into the wild and became added value for the company. But I also had this happen with another piece of software that I wrote for myself. The way it grew organically based on business needs makes me think about how No Estimates can be appropriately applied in similar situations.

Working with Time Clocks
In addition to working with automated turnstiles, I also worked with the time clock system. Specifically, I worked with the time clock hardware and data collection. This was then transferred to the time tracking system (which was the "system of record" when it came to time tracking).

The time clocks worked with similar hardware as the turnstiles, and so I would check them every morning to make sure that the everything was online. Initially, I used a set of SQL scripts to check this, but as you can imagine, I ended up writing a little application to help me out with this.

This application had a drop-down box that listed all of the time clocks and a data grid to show the latest transactions. Again, I could easily scroll through the drop-down and see which time clocks were reporting data. This required a bit more thought, though -- some time clock locations were used more heavily than others. For example, the time clocks at the site entrances had a steady stream of transactions, but the time clocks that were in the maintenance shops were only used by a small group of people, so it was normal to have sporadic transactions.

Escaping into the Wild
The scheduling team would use the time tracking system throughout the day. They would make adjustments if someone clocked incorrectly (or forgot to clock in/out). And they would also check for "no shows" -- people who did not show up for a scheduled shift.

Because of this, the scheduling team was more dependent on having the data consistently sent to the time tracking system throughout the day.

One of the schedulers saw my application and said, "Can I have that?"

And the reason turned out to be pretty simple. If he saw a gap in the time tracking system, he could check to see if a particular time clock was off-line. If an employee regularly clocked in at the west entrance, he could check the 3 time clocks at that location to see if they were all reporting data.

If one of the time clocks appeared to be off-line, then the scheduler could contact my team to have it reset. This gave them better visibility to the system, and they knew that if a time clock was off-line, they would not necessarily mark "no shows" for people who normally clock at that location.

More Features
I think it's good when a business area asks for more features. It shows that they are thinking about the technology and data that we have provided to them and coming up with new ways to use it. So, I wasn't really surprised when I got a request for more features in the time clock viewer application.

We had security swipes at the entrances to the site. This would allow the security team to easily check that people were allowed to enter the property. The employees would swipe their card, and get a "go" or "no go" based on whether they were an active employee (cards would get automatically disabled if someone quit or was let go). But this also meant that people who needed to clock in had to swipe again at a time clock.

To streamline this process, we combined the security system and the time clocks. We used the time clock to collect the card swipe (either a bar code or RFID) and then pass the card information along to the security system for validation. This resulted in a single swipe for people who needed to clock in as well.

But there was a process issue: the employee would need to press the "Clock In" button the time clock before swiping his card. If you did not press the button, the security swipe would be processed and you would be allowed on property, but a time clock record would not be generated.

"I Forgot"
As you can imagine, when people do this everyday, sometimes they forget to push the button (as they are maybe rushing too quickly one day), or they think they pushed the button but it didn't register, or they simply forgot to check for the "clock in accepted" message that would normally display.

If someone forgot to clock in, the schedulers could manually add a record to the time tracking system. But because this was a common occurrence (especially when there are several thousand people clocking in throughout any particular day), the schedulers wanted a bit more information.

You see, some employees had figured out a way to game the system. If they got to the clocking location and found that they were 2 minutes late, they could "forget" to press the "Clock In" button and ask their scheduler to override it. This would mean they wouldn't get penalized for being late.

So the schedulers asked if there was a way for them to get the time clock data combined with the data from the security system. This way, they could look up an individual and see what time the security swipe went through. This would let them check to see if people were actually late when they came in, and it would allow them to separate the people who forgot to clock in from the people who "forgot" to clock in.

Business Changes - Things Get Complicated
Whenever you deal with time tracking, things get really complicated. There are federal and state regulations, there are company policies, and there are union rules -- all of which need to be followed.

One change that came about was the ability to clock in and out at your work location (instead of the property entrance). The reason is that it could take 10 to 15 minutes to get to your actual work location from the property entrance. You were supposed to be at your location and ready to work at your scheduled time, so having a time clock at the location would help better track that.

Unfortunately, the time tracking system didn't have this level of granularity. It kept track of "clock in" and "clock out", but not the particular time clock that was used.

So, we were asked to come up with some printable reports that could be used by the location managers based on the raw time clock data. These reports would allow a manager to see all of the clock transactions for employees in their area (based on their department identifier). The manager could double-check that their employees were clocking at the right locations, and they could coach employees who needed a reminder on procedures.

Later on, we extended the functionality of these reports to show "exceptions" -- such as people who clocked in but forgot to clock out, or for people who clocked in and out at different locations. This let the management teams focus on where specific problems lie.

And all of this helped the company comply with the various contractual rules and legal regulations that governed the time tracking of employees.

Wrap Up
So, here's another example of an application that grew organically as the business areas saw places where we could add value. And it's another good example of how No Estimates could work well in a changing environment.

And even though I've come up with some good examples of where No Estimates would be effective in projects I've worked on, I've also been thinking about some situations where it would not be a good choice. (I'll be writing about these soon.)

This doesn't bother me, though. No tool is perfect for every situation. I wouldn't expect that No Estimates would be a good choice for every situation, either. What's important is that we take a look at our current processes, determine what's working and what's not working, and look toward improving things where we can.

Happy Coding!