Don’t Use Frameworks

How many times have you heard that Framework fill_in_the_blank will save time and prevent developers from doing things their own way. Or Frameworks save time by eliminating some of the redundant work on application development.

These might be true, but how many times has a the same framework been proposed for creating a 5 page website, or using an entire logging framework to write the results of one job to a text file, when no one ever reads that log…

So I will create the following rules for when using a Framework is OK, if it does not pass this test, roll your own.

  1. Does the framework configuration/ training take the same time or longer than the coding of said functionality? If yes, don’t use a framework.
  2. Is application connecting to multiple tables for Create, Read, Update and Delete transactions? If yes, perhaps some type of database framework is needed, that could be it, don’t install an elephant when you need a mouse.
  3. Does application require standardization for reuse/resale or for multiple programmers of varying skill? If yes, use a framework unless it contradicts with rules 1 and 2.
  4. Is application or library going to be reused and distributed open source? To facilitate the code and adoption it’s often easier to create when people are already use to the patterns and coding of an application, in this case, unless it contradicts with the rules above, use a framework.