Close

Problem Solving and Personal Development Time

Salim Uddin

Software Engineer

Im always clapping with one hand.

Behind one of the director’s desks in the dev office is an overcrowded white wall that has, among other things, a list of projects that developers can choose to work on as part of their Personal Development Time (PDT). All software engineers at Web Apps have half a day a week scheduled to work on something that interests them, such as creating an app or game, working towards a certification, or simply learning something new. The projects on the wall are mainly tools that can be developed to make our lives as developers more efficient, as we’re always looking for ways to improve our everyday processes.

Ryan and I picked a problem from that list that seemed worth solving and we have been collaborating on it for the past few months. Working together on a project has meant that we’ve not only had to deal with the task at hand, but also with the challenges and advantages of working together and making our Personal Development Time not so personal!

The project that we chose is an automated time logging system that checks and sends out email notifications to employees who have not logged all of their working hours. Currently, the emails are sent out by our Admin team who must manually review the reports daily to see how many hours someone was expected to work and how many hours were logged into the system. This can be tedious and inefficient, especially when something can be done to make the process easier.

This is where Ryan and I have decided to step in and help solve a problem. There are certainly some gaps between the both of us in terms of technical knowledge, but we don’t believe that to be a stumbling block to working on this project. If anything, it’s more of a reason to work with another person as it provides the opportunity to teach and learn – not to mention that there will be plenty of times where more than just one of us is learning something new.

The first step in our project was understanding the problem. Ryan and I dedicated some time during a PDT session where we discussed the main issues with the current way of sending out emails. Then, we tried to find a solution and break the problem down into smaller, manageable and programmable parts. Our solution is to create a programme that would run as a service in the background. It would do the hard work which our Admin team is currently doing and send out emails automatically to individuals.

To do this, we have broken the project down into several main components. We decided that we would create the project in C# using the latest .Net Framework. The programme would contain three main parts, which are FogBugz – to get lists of intervals for specific users, Exchange – to retrieve calendar information, and the Core – to contain logic that would take in the information from the two API classes and send emails if someone did not log sufficient time. The API classes (FogBugz and Exchange) will translate data so it shapes to Core classes requirements, as the Core will be as generic as possible. The reason for this is if we migrate from FogBugz to another system, we would only need to change the FogBugz classes, and the Core would remain unaffected.

As part of this project, we are also taking a test-driven development (TDD) process approach. Ryan suggested this process of development and we discussed it at length to decide if it would be a good tool for this project. Although TDD has a somewhat mixed reputation amongst developers, we believe it to be a good approach to developing this project. We think the TDD approach will encourage us to critically analyse and design the project by ensuring that carefully considered automated unit tests for each feature get written before the code, which will provide constant feedback that each feature is still working. Also, we will be writing code to meet real use cases, such as a person that should have logged no less than 3.5 hours if that person had a half-day. Some other benefits of this process include generally better designed and easier to maintain software, and less debugging time. This is my first TDD project and naturally there are new things to be learned from this as well.

To return to the challenges and advantages of collaboration, I’ve found that there’s a lot to gain from working on a shared PDT project. I believe when you’re cross-pollinating thoughts and ideas, you see things in ways that you didn’t see before. Ultimately, solving problems together is much more effective than solving them alone!