27 June 2014
Technology Is Not One Size Fits All
When I turned 16, my first ‘car’ was a 1984 Chevy 1500 4x4. Shortly after turning 16 I found my love for Formula 1 Racing and all things that go fast. What I quickly realized was that my old farm truck would never be either of those things.
In the physical world, we are able to quickly discern when things don’t fit. Our brains are trained in this regard at a very young age as we try to shove a square block into a round hole. Why then, when it comes to programming technologies can we not see when things just don’t fit? Why do we allow ourselves to suffer through using some new language or framework when it is clearly painful?
As developers we are faced, almost daily, with the decision of which tech stack we should use. And with new languages and frameworks being released constantly this decision isn’t getting any easier. We end up acting like raccoons falling for a trap, chasing the shiny thing, never realizing that eventually this will become painful. I have fallen for this, just as we all have, but how can we mitigate the pain?
Trying a new library, framework or methodology is not a bad thing, but try to do it with minimal risk to your client or product. Start in a time box, set a timer if you have to, and say “I am going to spike on this for 3 hours”. For me there is no greater shame than going to my client or product owner having wasted hours or days trying something new that didn’t work. If the spike fails, there is not too much to recover from and still deliver the feature on time.
Recognizing the pain is probably the most difficult part of this for all of us. At what point can we say the pain is too great and call our effort a loss? For me, it is when I start saying things like, “I could have solved this easily in technology X”. Or when I open my editor and stare blankly like a deer caught in the headlights. At this point stepping back and re-evaluating the decision to use this new technology is key.
There should also exist a hard limit on the number of new things to try in a project. Buzzword technologies are everywhere, and trying to munge them all together in one project is sure to inflict the most pain. Taking the time to evaluate the one that fits your project and use case, seems the most logical approach.
Trying new things is vital to the survival of the programmer, if we didn’t, we might all still be using punch cards to write our programs. Trying new things which harms my project, causes stress or pain, or introduces tension amongst my team is the exact opposite of survival. Save the stress and pain for when your child starts dating, and minimize it in your project today.
