Software Gear Shifting

I was riding my new bike today with my son in the trailer. We went everywhere, to the park, down a green belt, through the neighborhood, always at different speeds and always changing gears. As I approach my house, there is a small hill that I need to climb in order to get the bike and trailer into my garage. I was not paying attention and forgot I was in high-gear so as soon as I went up the hill, the resistance was too strong and I got stuck.

I've gone up this same hill, in the same gear, everyday for about two weeks straight. So, why did I forget to shift this time? I almost immediately related this problem to software and my short programming career.

Over the past year, my programming skills have evolved rapidly and I'm constantly learning how to be a better programmer. With that comes a different mind set during development. For example, I just completed a major engineering effort on one of our product's website navigation system. Think of it as a database driven site-map on steroids, complete with contextual options, event bubbling, keyboard support, layout options, styling options, oh and did I mention its contextual? This challenge only took me a couple of days to write, test and implement. A year or two ago this would have been a side-project (in fact it once was) that may have never been finished.

During the short lifecycle of this project I found myself thinking of things that would have never crossed my mind before. Things like, this method should or should not be static, or this method does not belong inside this class. I even took it as far as "what would the solid principles of design or WWSPDTMTD as I like to call them" tell me to do in this situation. With every line of code I wrote I kept thinking, make sure this thing is scalable. Make sure it is extendable, make sure it works...

I feel like I went above and beyond what was required. I component-ized the class objects and built controls that other programmers could implement later. I have no idea if the controls will ever be used again, but if they are, I'm confident they will work and the programmers that implement them can do so with very little effort.

Again, this is such a change for me from a year ago. I was a green programmer who eagerly wanted to bang-out as much code as possible; I did not pay much attention to code purity or scalability, rather I just made sure it worked. The more code I wrote and the more involved I was with important projects; it seemed like people looked at me with higher regard. After no time at all it was apparent that I became the go-to guy. Being the go-to guy comes with some heavy weight on your shoulders. Not from your peers, or your bosses, but from yourself because you are the one that sets the bar for everyone else.

Once you are a go-to guy, or gal, you touch nearly everything. System problem, you get the call. User problem, you get the call. Business needs a new credit card process written and implemented in two days, you get the call. The experience that you get starts to grow exponentially with each product you build, feature you add and or bug you fix. Get enough bug fix requests thrown your way and you realize you are fixing your own code. It may not be the code you laid of finger on, but it is the code that you are responsible for. It is code that was written in a way that you would have done when you were green.

Don't get me wrong, everyone writes code that they could say "I could re-write that better", a few years after they've written it. I'm referring to the "what the hell was I thinking" moments, or the, son-of-a-biscut, I have to re-write this thing now so that its a little more generic and can be reused by other objects.

So things have become so clear to me now. Do things the right way up front and you wont have to fix them later. Sure, it may add a few hours to your LOE (Level of Effort) now, but that costs you and the business much less than fixing it later when it is a bug and a fire-drill ensues until you force a deploy to squash it. Spend a little extra time and consider scalability, flexibility and extensibility when writing code. I've learned this the hard way. I like to move forward, not backwards, and to fix a bug I created, or to re-write code I've already written before nearly drives me insane.

When I look back at the navigation project and the extra effort I put into it so that other programmers could use it in other applications, I'm convinced that I did it twice as fast, if not faster, than I could have done it a year ago. So tell me, was there business savings in that? You bet your a$$ there is. Not just in the time I spent on it, but in the time we will save when we tell programmer X over there to implement the same navigation system on this other site.

Ok, so now that my rant is over, here is the point I'm making about Software Gear Shifting. It should be our goal as developers to build software that is bug free, easy to change, scales well and that people like using. We should make sure our users never feel like they are going up a hill in 24th gear, when using our software. It's not just about the users either. Other programmers should be able dive into the code and develop it, not fix it. The software as a whole, meaning the code, and the UI, should work like a bike, which can seamlessly switch gears with very little effort. If you haven't guessed already, Software Gear Shifting is a really long way of saying Agile.

As for me not making it up the hill... That was my mistake. I went back down the hill, re-shifted to first gear and took us up the hill.

Powered by Qumana