Technical Debt and the Drawbacks to Rushed Development

Since concluding my work with GermTheory, I'm finally getting the chance to take a breather and revisit some of my own projects. Naturally, my first thought is to go back to finish Schedulize, but I've been disappointed to find a number of shortcomings in the application that have become significant hurdles to completion. In the 2 months since initially architecting my application, my outlook on the stack architecture has changed considerably.

Given the hurdles of building on top of the existing system, I've decided to rebuild schedulize from the ground up. It was a hard decision to make, but I'm confident that it will be the right one.

At the risk of sounding like a poor programmer here, I want to draw attention to some of the technical debt that I accrued through the quick development of schedulize.

  1. I structured the app using a MEAN(MongoDB, Express, AngularJS, NodeJS) stack, but I elected to implement three separate angular applications throughout the site. This made sense at the time, but it inherently feels like an antipattern if I'm using AngularJS. I love angular, but I think going forward, I'll rebuild it using ReactJS. It's a framework I've wanted to dive into for awhile now.

  2. I completely wrote out my version of the Ford-Fulkerson Algorithm, but I designed the entire operation to run as a client-side process, rather than running it server side. This is a minor issue, but it would have resulted in lengthier development times and some tough refactoring.

  3. I struggled to use an ng-repeat to display a table of times for users to select. As a result, I had to use a hacky fix that compromised code readability. It was some of the least legible code I've ever written.

  4. I initially created the application to use Moment.js to track shift times before realizing that Moment automatically treats all times based on the originating time zone. This proved to be an issue, and it led to complexity storing the values.

  5. The code is completely illegible. I only had three full days to build what I could, and unfortunately, that never lends itself to a good finished product. At this point, I've decided my best bet is to move forward differently.

Where to go from here

As mentioned above, I've decided to rebuild the application from the ground up. My server architecture will look extremely similar to before, but I have other plans for the front end.

I love Angular, but I've been extremely intrigued by ReactJS and Flux, so I plan to rebuild the front-end using those frameworks instead. Similarly, my calendar view was a complete disaster before, so this time around, I'm hoping to incorporate FullCalendar, a convenient jQuery calendar for dragging events. This should ease the availability process.

Overall, it's a great learning experience to look back on old code that I've written. Much of it will certainly be used in the new version(especially the Ford-Fulkerson algorithm), but I'm certainly looking forward to a new beginning on Schedulize!

comments powered by Disqus