Over a million developers have joined DZone.

To Use a Framework, Or Not?

Inspired by a recent Uncle Bob post, the author contemplates the decision to use a framework.

· Java Zone

Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.

If you haven’t read Uncle Bob latest blog post, you should do now. For impatient readers, it can be summed up with:

TL;DR: You don’t need frameworks, just write the appropriate code.

It’s not the first time I find myself at odds with Uncle Bob’s writing, which feels awkward in regard to his experience and aura. Another post that drew my attention was about JavaScript. Again, you can read it… or:

TL;DR: It's better to understand the underlying layer than become a framework specialist.

That I can understand. In the JavaScript ecosystem, a new framework pops up every six months and becomes the new hype. (Fortunately, I’m a Java guy and it doesn’t happen so much in ours.) Yet, is it so strange that recruiters want someone productive in the framework from day one? If to make a parallel, I’d really like the pilot of my plane to be experienced in that exact type of plane, not a random pilot that can learn “on the fly” (pun intended).

As for software, why would anyone in his sane mind still use a framework? Because frameworks are about being productive i.e. saving precious time! Something like Joda Time might not be the next best thing since sliced bread but it’s nicely designed and readily available. Could I cook something like this? Probably, given enough time. But here lies the rub: in a project, you don’t get time to create your own low-level libraries. There’s a budget and you better not overspend. Anyway, should I have time left, I would prefer to increase my test coverage, run some some mutation testing or refactor parts that need it.

Refusing to reuse even has a name in software engineering - the NIH syndrome. There have been several examples of developers developing their own custom framework instead of an existing one because they thought they understood the problem better than others. It usually ends up in a tangled mess of half-baked code, with zero documentation and a huge learning cost. Interestingly enough, examples I personally witnessed first-hand are about data persistence. Folks, don’t do this at home! Or better, do it at home for learning purpose, bu don’t do it at work…

There are a couple of hints that let you spot NIH:

  • A company policy prevents you (or hinders you so much it prevents you) from using a third-party library for “security” reasons – though Open Source code is much safer than closed source, thanks to the power of reviewing. You’re welcome to read this piece of art from Oracle stating the opposite, which has been removed since.
  • A person enforces the use of the code he/she developed, even though it’s not documented or tested, and a solid Open Source framework does the same but their position of power prevents to do otherwise

Of course, when you need to use a framework, that doesn’t mean you should use the first one you stumble upon. I firmly believe that knowing a couple reliable frameworks in different domains (logging, reactive, UI, metrics, etc.) should be part of a well-rounded software engineer portfolio.

One has to look at a few things before making the choice of using a framework, but they can be summed up in one question: “Will it be maintained?” This criteria can be evaluated through a couple of factors:

  • Number of committers
  • Frequency of commits
  • Date of last commit
  • Documentation
  • Nature of the licence
  • Size and activity of the community
  • etc.

All the frameworks I use (SLF4J for logging, Vaadin for UI, Spring for Dependency Injection, etc.) score highly in those areas and will probably outlive the applications I use them in.

I agree with Uncle Bob on one point, though: one has to understand how it work. I remember 10 years ago when the Java EE world (J2EE at the time) revolved around Struts. Junior developers were brought in, trained in Struts, and released in the wild to code Struts applications – most of them didn’t care about knowing the Servlet API underneath! I was shocked that as a software developer when someone was not curious enough to understand what happened under the covers.

But you have to stop somewhere. Software development has a history of adding abstraction layers upon layers to get closer to the domain model. So it sure is nice to know that Vaadin is built upon AJAX and JSON, that produces HTML, that is sent over HTTP. But frankly, I will stop there. I don’t need to understand how every bit of memory is handled in the end, do I? I’m afraid dogma doesn’t handle well real-life constraints. That said, the more you know, the better it is.

In conclusion, I’d suggest everyone to make their own opinion: try using frameworks or don't, and see how it goes depending on the context. But more importantly, don’t take anyone’s opinion to justify your lack of arguments taking one stance or the other.

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

framework ,java

Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}