It is the plight of the modern software engineer to know that there is always more than one way to solve a problem. Often we struggle with trade offs between usability (our own) and performance (the users). Eventually we individually or collectively chose “something” only to find that a single choice then cascades through our entire solution. If you don’t believe me you can validate this for yourself. Just ask a software engineer their “best practices” for managing dates and date logic and watch their eyes roll.
For my part, I’m just as bad as the rest. I chose scripting over compiled for the instant gratification. I chose free over commercial because I’m cheap! I chose frameworks for their lightness, ease of use and ability to get out of my way when I need them to. I chose operating systems for their ease of use rather than cost because I have no passion for fighting obscure OS’s.
It is in the midst of making all these “choices” that I’ve come to realize why modern software is the way it is. Choices, made by developers with the best of intentions, will drive the evolution of a product deep from it’s very core architecture on through to the user experience it eventually will present. This is not universally true, but in commercial offerings from all but “the biggest” providers this is often easy to spot. The question is, do we care. The answer is, we better if we hope to evolve past this point.
As I thumb through my copy of Algorithms in C++ I’m reminded that although ease of use is arguably more of a subjective measure, performance at the very high end of the spectrum is materially impacted by built to purpose. As a for instance, take the Relational Database Management System (RDBMS). The spread of these solutions has been matched in equal measure by the explosion of built to purpose (domain specific) applications that dot the software landscape today. This was all well and good, until the recent growth in high performance, high availability and high user count solutions that the web community now demands. Software engineers have quickly begun to look beyond the venerable old work horse that is the RDBMS towards distributed document based database management systems or the cloud as some prefer to call it.
The problem is, document DB’s are good for some solutions, but they are not ideal for everything. Yet recently I’ve seen people assert that all DB’s should be document based. It is here that the trouble starts. Human nature is to find the “best” way to solve a problem and then always solve it that way. Software, really good software, is about finding the best way to solve a very specific problem, but also about having the intellectual awareness to recognize that other problems which may look “very similar” are in fact different enough in their need to warrant a different approach. The challenge becomes how to create tools such as frameworks or even open or closed platforms that will help us scale and adapt our solutions organically without changing code in every part of the application. This is no small task.
This is the holy grail of the passionate software engineer. To build a solution that is usable and scalable without becoming brittle. As we look in our tool box we are convinced that we have enough of the basic building blocks to achieve this result. We try and try again. We spawn new projects, frameworks, patterns, approaches, and slowly, painfully, we move the ball forward. We are not there yet, but I think that big gains are coming. To that end I will keep making choices. I will chose each building block I need through the filters and lenses that work for me. I will keep my mind open and objective. I will do “just enough” to achieve what is needed for my solution, but I will also carefully review every choice to determine what it’s implications are for tomorrow. Performance and flexibility will continue to color my perception of each new tool. I encourage every passionate software engineer to do the same!
