A Project Story On Technical Debt

A reflection on my code journey at The Iron Yard, relative to the ideas in this article: http://firstround.com/review/shims-jigs-and-other-woodworking-concepts-to-conquer-technical-debt/

I wouldn’t be honest if I said I didnt experience much technical debt so far in my coding career. In fact, it seems that much of what I write in terms of code would create some crazy technical debt if any of the software projects that I’ve written so far were actual web applications.

Most recently, the front end weekend project for the end of week 8 was quite hefty. I took to the assignment after receiving some advice to go ahead and start even if there were some other projects lagging behind — definitely feeling the pressure with final project pitches looming in a couple days, while trying to get caught up before this week ends — inadvertently scrambling and creating technical debt in my projects while doing so. I started with the recipe adjustment calculator requirement and tackled that going into the weekend not knowing with certainty how long this process was going to take.

It turns out, newbie coders are almost always going to create technical debt. Better code is not always as straightforward in those beginning stages, and the road to the end goal feels like it is winding constantly as you work through your code. Sometimes you’ll hit rough patches, and that shortcut route that you took — the easy, more seemingly simple route — may trip you up later on and cause you wipe out.

This project was no exception. As I dug into the meat of it — first creating all of the HTML necessary to represent the components that I needed to build and then transferring them into static React components, building the Backbone models and collections and using dummy data to simulate possible real data being loaded to the applicaiton. That was all well and good, and I was on my way to building the form I needed to submit actual recipes.

Figuring that since I had decided to go with a simpler database structure for such a small project, I was going to forgo messing about with a Backbone model and collection in the correct way to handle the dynamic ingredient inputs on my form, and just add empty models to the collection and print a new ingredient field group when each one is added, and just pass the result of that to the Parse server — then the conversion to JSON wouldnt be needed, right?

I probably wouldve done myself a favor had I heeded the comment on the line in the code above where I was working:

// hacking the collection for more form inputs

I went on to notice that the behavior wasn’t exactly what I had intended, but confident that I would perhaps be able to shim in the functionality I wanted. Turns out, trying to shim some functionality in where otherwise you could’ve just done it correctly in the first place wasn’t a great idea.

I now had some technical debt to pay. I’d go on to refactor the code to produce a legitimate model and collection for that part of the form, and thus produce happy results that im confident that the server will play nice with. That debt was paid with time — time that I should’ve been using to hook my app up to the server to start getting real functionality.

Now, only time will tell over the next day or so if I have yet to pay back some more technical debt — either from trying to shortcut myself or simply not knowing.

Onward, to finishing this one off!