Sometimes you need to stretch out

There are moments in life that REALLY stretch you. Sometimes those moments are personal, such as a rough patch in your significant partnership, or an illness in the family, or even yourself. Sometimes those moments are sports related, such as an injury in the middle of a big game, or a slump in performance.

Professionally speaking, as in my career, I have just endured one of the most emotionally and mentally draining projects to date. I choose the word endured deliberately, because for me, it was a grind! The most frustrating part of the project was that it wasn’t a particularly challenging project. The requirements weren’t staggering. There wasn’t any technical detail that was beyond my grasp, or knowledge base. The project in and of itself was rather innocuous actually.

Every now and then, we all come across that project that throws curve balls at every turn and this project was exactly that! For at least two solid weeks, I felt like I was chasing my tail! I would make a change in one place and something would break in a totally unrelated part of the application. Course, I didn’t check for that, assuming everything is JUST fine, only to present it during a demo and the first thing we try is the now broken piece of functionality! YAY ME!

So, all of this is worthless if you don’t learn something from it and grow. What did I learn? Sometimes, things aren’t always as simple as they appear on the surface. Sometimes the complexity is in the details! As it turns out, even though the requirements of the project were fairly straight forward, there enough components interacting together at once to make linking them together in a meaningful way far less trivial than it appeared at first glance. I also learned that when you’re dealing with this kind of complexity, it’s best to LITERALLY map out ON PAPER what needs to be done – down to the very last nail and rivet! Or, in this case, semi-colon and curly brace. At this point, I’m sure many of you are remembering your software design course (because I’m sure we all took them, right? Right?!) and the voice of your professor saying “Map out the use cases. Map out the entities and how they interact. Define the interfaces for your classes.” It would appear I completely ignored every single software design lesson and just charged into the project, realizing far too late that I had coded myself into a corner.

In this industry, time is money. Sometimes, take those extra hours, or even days, at the start will literally save you weeks down the road. This is a lesson hard learned. What should have been no more than four to six weeks, soon stretched out to 15 weeks, causing much frustration for me, my boss and the client. Hopefully, this experience is one I never have to repeat again.

I can tell you one thing. From this point forward, I’m definitely writing out the requirements of my projects on paper, no matter how simple they appear to be. With all the technology available to us these days, sometimes the best tool is the one that’s been around for hundreds of years.