A Wild Goose Chase: Building the Perfect Application

I was participating in a thread today on the ACFUG email list and something occurred to me about many developer's mental quest to develop the "Perfect Application". The thread was about the use of "SELECT *" in SQL code and debated the real performance cost or gain from using or not using "SELECT *". Lots of people had opinions, and in the end a semi-consensus was reached that while it was important to consider the implications of using "SELECT *", there are plenty of scenarios where it doesn't really matter. So many development questions are answered with "it depends". On the CFCDev list, I see so much "it depends" that I can predict the contents of some replies before even opening them. If I only had a nickel... But "it depends" isn't satisfying! A frequent lifecycle of a CF developer begins with a budding newbie roaming email lists and websites seeking "rules of thumb" and dutifully collecting them, jotting them down and attempting to "follow all the rules". They may learn that "SELECT * is evil", that "stored procedures are better for performance", or that slightly different syntax in an if statement results in some virtually unperceivable performance gain. As your bag of tricks grows, you mentally start to build the Perfect Application in your head. You think that if only you could implement all the things you've learned in one application it would be Perfect! It would be speedy and sexy and would finally prove you've arrived as a seasoned developer! As you continue to grow as a CF developer you realize that this list is not, in fact, the guide to the Perfect Application. You learn that while using Stored Procedures can speed up code, it can also increase development time and make the code less portable. That your tweaked if() statements are confusing to other developers on your team and slow development down. One by one each Rule of Thumb from your collection is slowly disassembled as you learn that there are very few actual Rules of Thumb. Perhaps along the way you discover Design Patterns and add them to your list, only to find out that they too have exceptions. In the end you realize that there is no such thing as the Perfect Application. Every rule has it's exceptions, and everything has a time and place. The makings of a great developer include not only knowledge of the tricks from your former Rule of Thumb list, but when NOT to use them.

Comments (5)

Add Comment ]

Doug Are we really looking for the "Perfect Application" or are we learning how to use the tools? By looking for the unattainable perfect application, I am learning how to use the tools that are available and possibly creating new or better tools. The discussion on the merits of 'stored procedures' or 'SELECT *' has value to many of us learning to be better programmers. While the concept of 'Best Practice' will always be fluctuating, I find the discussions on these ideas to be real eye openers.
Because there is so much to learn (I can't seem to do it fast enough), this forces me to take a few things (i.e., SELECT * is bad) for granted, in order to understand the whole picture. Going back and correcting these ideas is easier than dissecting each one as they appear. For better or worst this I look to people like yourself for guidance.

Thank you for every word.
Cameron Childress It is really a learning process. In posting the Perfect Application scenario I was also trying to explain the thought process that went on in my head as I have learned, while is very likely the same process many (perhaps not all) others have.
Nelson Winters Hey Cam, Excellent post. I've definitely been guilty in the past of chasing the wild goose (or was that the Wild Turkey?). Another problem with trying to create a perfect app is that it usually never get's done. While the app is being developed, it is inevitable that "better" solutions to already completed parts will present themselves leaving the developer in a quandry since the goal is to create the perfect app. This certainly must be rectified. From here, the software development cycle breaks down and the developer is caught in a never ending cycle of self-imposed changes to a non-completed application.

This illustrates how 80% of developer's time can be focused on just 20% of an application. The 20% is what makes an app perfect, and there is no perfect app.

-Nelson

Ray Champagne Thanks Cameron, I found this insightful and shared with some co-workers. We all tend to do this, even 10 years into our career.
Cameron Childress Glad you liked it! Oddly, it's just as true for me as it was when I first wrote it. Being aware of this doesn't mean you will stop wasting time sometimes chasing perfection in an application. :)

Add Comment ]

Post a comment





Leave this field empty: