Your [type of framework / tool] Choice is Not a Feature of Your Application

Tim Barcz posted a great article on how the specific choice of an IoC container doesn’t really mean much in the grand scheme of the application. This line, at the bottom of the post, really sums it up for me:

Choosing one container over another won’t make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice.

It’s far more important to have good patterns and practices that allow us to implement architectures that are maintainable and able to scale appropriately, than to have “that one specific framework” vs “that other framework” (or no framework at all). And it’s a fairly small step to apply this idea to any other framework or tool that we want to use in our application development. Change one word – “container” – in that quote above and see how it affects the decisions we make:

Choosing one [type of framework / tool] over another won’t make your application a success. The architecture, or lack there-of, will have far more of a say on the success of your application than will your [framework / tool] choice.

Of course, there are times when there are specific needs and valid reasons for choosing one tool over another. Be sure to read the comments on Tim’s post – the subject of valid reasons for changing is discussed more, and I really like what Tim has to say about it.

Why “No Issues” Is Not An Acceptable Answer