The flipside of this is that using a framework without first understanding it is asking for trouble down the road.  If you look at Rails and go &quot;Great!  Now I don&#x27;t have to understand how the stack works, I can just put some templates down and have a custom blog!&quot; you&#x27;re going to be the guy who discovers that his system is slow and riddled with security vulnerabilities because you didn&#x27;t take the time to understand how all of the parts of the platform interact.<p>This is why I always groan when I see a &quot;solution&quot; that involves bolting together dozens of different libraries (all out of date because updating any one would break the rest of the system) I know I&#x27;m in for a long day.<p>Using libraries is certainly a good thing and saves lots of time and effort in the long run, but they take more thought than most people are willing to put in.  There are no shortcuts if you want to keep your company out of the newspaper as the next big data leak.<p>Wordpress is an excellent example.  Even if you have the basic system down and have the management handled (either in house or externally), there&#x27;s a dizzying array of interactions with the plugins that can shoot your foot right off.  And don&#x27;t think the Wordpress developers thought of all of the edge cases for you, they have their hands full on the main platform:<p><a href="http:&#x2F;&#x2F;www.cvedetails.com&#x2F;vulnerability-list&#x2F;vendor_id-2337&#x2F;product_id-4096&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.cvedetails.com&#x2F;vulnerability-list&#x2F;vendor_id-2337&#x2F;...</a><p>At the very least you need to know enough about any solution to deploy to turn off all of the features you didn&#x27;t configure&#x2F;don&#x27;t understand&#x2F;don&#x27;t need.  So many vulnerabilities these days happen in features you didn&#x27;t even know you had.<p>I know the popular saying is to never write code that you don&#x27;t have to, but IMHO it&#x27;s less of an evil to write your own couple of hundred lines of glue than to pull in a 100MB package that depends on a dozen other packages just to get that one mandatory piece of functionality.<p>Most code rot comes not from the code itself going out of date, but from its interactions with external dependencies.  Managing the number of dependencies makes maintenance easier in the long run.  There&#x27;s nothing worse than a mandatory security update for a module that breaks another external module that is no longer maintained upstream.