Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] how to decide on whether to use a framework

Expand Messages
  • Curtis Cooley
    ... Hibernate lives on the very edge of my comfort zone when it comes to frameworks. ORM tools are nice, and abstract you away from the database and SQL. Plus,
    Message 1 of 6 , Jun 19 2:05 PM
      On Fri, Jun 18, 2010 at 10:35 AM, Adam Sroka <adam.sroka@...> wrote:
      > The canonical XP approach is to defer design decisions until the last
      > responsible moment. This is part of the practice we call Simple Design. That
      > can be difficult to apply, but if you can learn to do it you will reap a lot
      > of benefits.
      > Unfortunately, the design of most frameworks is antithetical to this idea.
      > That is because framework builders need to anticipate the variety of
      > different ways their product may be used and build in enough flexibility to
      > enable them. By doing that they are accepting a certain amount of accidental
      > complexity (http://www.bigvisible.com/asroka/essential-complexity-part-one/).
      > By pulling their framework into your project you are accepting all of that
      > accidental complexity, plus whatever additional complexity is necessary to
      > make their product fit your needs.
      > So, most of the time using frameworks is probably a bad idea. However,
      > sometimes frameworks can actually save you a lot of effort without greatly
      > increasing complexity. How do we tell the difference? Here are some things
      > that have worked for me:
      > 1) prefer frameworks that do one thing well. Smaller simpler frameworks are
      > less likely to significantly increase the complexity of your product,
      > particularly if their purpose and use is well aligned with your needs.
      Hibernate lives on the very edge of my comfort zone when it comes to
      frameworks. ORM tools are nice, and abstract you away from the
      database and SQL. Plus, when used well, it also abstracts you away
      from your specific database implementation. They also conform to the
      80/20 rule, and that 20% of the things they don't do well could suck
      your project's resources dry.

      Consider getting an expert. ORM tools are often dinged because they
      are slow. A week of a hibernate expert's time could go a long way to
      getting you that performance boost you need. JVM tuning comes to mind
      here. It's really an art, and you can spend a few weeks trying to
      master it yourself, or bring in an expert for a day or two and be

      > 2) prefer frameworks that are developed in an evolutionary fashion.
      > Frameworks can either be designed to solve some theoretical problem or grown
      > to solve some real problem. The latter tend to be simpler and more focused,
      > and they are particularly good if they are solving the same problem you need
      > to solve.
      I thought of Rails when I read this part, and it's really good advice.
      Look into the history of the framework before you start experimenting
      with it. Was it abstracted out from 'real' projects, like Rails, or
      built from the ground up to be a framework? I'd run away from the

      > 3) Grow your own framework. Like Joshua alluded above, often (usually?) the
      > best solution is to build the framework you need in an evolutionary way
      > using TDD. If you do that, and you follow the rules, the result will be a
      > framework that is no more complex than necessary to solve your actual
      > problem. Some of us have found that this approach is actually faster and
      > more effective than using someone else's framework in a significant majority
      > of cases.
      This is perhaps the best solution, but be weary of the "not invented
      here" anti-pattern. One thing teams often don't realize is that when
      they build there own, they learn things they would not have learned
      any other way. That can not be taken away, even if you someday replace
      the home grown framework with a commercial one. Once you've built one,
      evaluating and using a commercial framework will be a piece of cake.

      Curtis Cooley
      Leadership is a potent combination of strategy and character. But if
      you must be without one, be without the strategy.
      -- H. Norman Schwarzkopf
    Your message has been successfully submitted and would be delivered to recipients shortly.