<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 2:37 PM, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ws" class="a3s" style="overflow:hidden">First of all, let me say that it does depend on what you're out to<br>
accomplish and in what time frame.</div></blockquote></div><br>Indeed, the great lure of frameworks are they make prior choices for you under the pretense the choices are correct and useful for your problem. By making the decisions quickly, you get a minimum viable product faster and have a shorter time to market. In turn, you gain the de-facto monopoly anyone hopes to get.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The same can be said about astrology. If the constellations and planetary bodies are just right, you will bathe in gold. If they are ever so slightly off, you will bathe in lead. And nobody told the astrologers about Styx or Cerberus, so they can't by definition have gotten the bodies right in their charts.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The crux of my argument is based upon the prior choice of features. First, you need prior knowledge of the framework itself. You need to know its performance model: what is fast and what is slow. You need to know the internal architecture. Otherwise, you are probably worse off than just writing the code. A network effect is apparent: the more you work in a framework, the more accumulated knowledge you have and the faster can you build new stuff. The 10th Rails project is easier to write than the 1st. Second, your problem has to match the frameworks framing, in the sense that the problem space you are facing matches somewhat well with that of the framework. As an example, it is hard to take the MVC pattern and fit into an Event Sourcing/CQRS model. Of course you could learn a new framework, but this requires prior knowledge as well.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So you need prior knowledge of what problem you need to solve, or it is square pegs through rounds holes all the way down.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My claim is that any interesting problem has high risk. In turn, any interesting problem is unknown by definition. Hence, you don't know a priori if your framework fits the problem in any way, and learning one is more or less hit-or-miss. You may get a lucky strike, but it was definitely not by considerate aiming of the weapon.<br><br clear="all"><div>This is why I prefer tools to frameworks. For a risky problem, the freedom of picking tools for the job dwarf the advantage of using a framework. I thrive much better by gluing my own solution together. </div><div><br></div><div>YMMV of course, depending on the task at hand and your prior knowledge.</div><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>