A small Maryland town, circa 1989: “Billy, come check this out!”, my friend called to me from the driver side window of his Trans Am. I walked over and climbed into the passenger seat and before I was even completely settled in, the sound system washed over me. The crystal-clear sound of Great White rocking “Once Bitten, Twice Shy” sounded all too perfect, and I could feel my internal organs thumping with the bass. I looked down at his dashboard at the night club-level light show emulating from his stereo system. My friend was saying something to me, but I could only see his lips moving. I was totally immersed. Once the show was over, he got ready to drive off. He turned the key in the ignition, and nothing happened. He tried again. Still nothing. He ended up having to replace the engine, but that stereo system was amazing.

“All Show – No Go!”

So how does all of this tie into a development blog? I ALWAYS think of that day when it comes to developing software. The engine has to be built and running smoothly before the stereo gets to be upgraded. Far too many times, developers fall into the trap of trying to build in “Bells and Whistles” that are perceived as necessities that the user just can’t live without, but in most instances that’s just not the case. The consumer shouldn’t be concerned that they will have to end up dealing an inferior product just because we put in a new feature that only a very small percentage of them will use anyway.

At Data Age, we always strive to make sure that we build good code on top of great code. Over the years we may not have always been the first to implement new feature functionality, but we are always sure to build over the foundational base code that was built properly, tested thoroughly, and proved it’s stability.  Just like my friend’s car, it wouldn’t make any sense to pack in a bunch of new features if the core software can’t handle the very basic of tasks.