BY JOE SUSSMAN, AUTOMATION ENGINEER

The first product I worked on was originally called GridApp: it was an application that helped enterprise customers manage their database infrastructure, which in most cases was widely-distributed and required the use of complex clustering software. I liked the name GridApp: at the very least, it was self-documenting. When we got acquired by BMC Software, the name was changed to BBDA, which would become a component of the BSA suite, which was part of the ESM portfolio of products. I should have expected as much from a company whose name was itself an acronym... Acronyms can be convenient, but other times they obfuscate meaning and lead to confusion. The same can be said for ambiguous names that are not acronyms. Oftentimes, the most confusingly-named solutions are the ones that hold the most allure for the uninformed.

In larger shops, where the non-technical are more numerous, there can be significant pressure to adopt the New. There is a tendency to namedrop when proposing solutions to the latest set of engineering challenges: all you need is Ruby on Rails, Hadoop or Jython. Do not take the bespoken approach (they say), using the simple tools that you know and love: use multiple off-the-shelf solutions that are complex due to their flexibility or that require significant customization to perform the desired use case. What could have been a one hundred line Python script is now a week of learning, the result of which is a first-time effort. Nobody gets it right the first time and those that do get it right the first time usually get it wrong the second time. You are left with with a solution that, at best, has parity with the one hundred line script, or at worst does not perform the desired use case, has bugs or is too difficult to maintain. All of this just to say "We used Jython"?

Resist the pressure to continually adopt the New just to (in the words of Larry Wall) "lengthen your resume by a word and a comma", or worse, impress people. There is plenty left to learn from the Old, and there is plenty of utility in it as well, not to mention economy. Software engineers often find themselves getting frustrated with six-month-old code, wondering what delusional person could have written it, only to realize that the author was their former self, not a former employee. Having this experience from time to time is just a sadistic pat on the back: it is an indicator that you are further along in "the progression" now than you were six months ago and that is great! Go ahead an refactor that code until it no longer offends you and keep practicing. If you ever do reach a point where you no longer get to reflect on your former incompetence, maybe it is time to learn Ruby on Rails after all.

 

Comment