Last week was one of the tougher ones I’ve experienced in a while. I struggled with several problems that threatened to derail one of my main projects. On top of that, I was multitasking a couple more projects than usual; each with their own ups and downs. By the end of the week, I was pretty much out of steam. Thankfully, everything ended on a fairly good note with all major problems resolved in some manner. I did find some time to set up a project planning page with links to the trello boards for each project. I’ll try to update the trello boards over the next week or two.
The major problems had to do with updating existing source code from an end-user software product. At first, I thought it was just a minor bug in one of the batch processing steps. So in the first half of the week, I evenly divided my time between that bug and 5-6 other tasks.
I finished several other tasks and, on day 3, I devoted a few hours to try to fix the “minor bug”. I quickly realized that the minor batch processing bug was actually the tip of an iceberg. There were large parts of the source code that required refactoring to meet some of the project goals. I put all other remaining tasks on hold and began investigating the extent of the required refactoring.
After two days, I finished my assessments and realized that over 90% of the source code required refactoring, and that it would take over 4 weeks to do. Additionally, there was no automated or even manual quality-assurance procedure to verify any part of the software would be working after such a refactoring.
Implementing a quality-assurance system for this project could take up to 4 additional weeks. Doing the refactoring without implementing quality-assurance would create the risk of software-breaking bugs being discovered by end-users, damaging sales and reputation of the software product and the company. That risk was out of the question, so my decision hinged upon (1) asking for a 2 month delay to implement QA and refactor the source code, (2) finding a solution for QA and refactoring which could be done within the current timeline, or (3) cancel the project goals which require the refactoring and redirect development towards a more feasible goal.
Ultimately, I decided that the goals which required refactoring were actually secondary goals that had no immediate benefit. So I chose to cancel those goals and redirect development towards tasks which would cause the least potential for bugs. This decision was especially difficult because it affected multiple team members and their work for the past 2 months. I gave everyone detailed explanations of all the issues, and reassured them that their efforts were not wasted.
On the last day of the week, the team started on the new redirected goal. We were able to finish those tasks that same day, and we even came full-circle to fix the original “minor bug” in the batch processing steps.