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 odd 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: "Better understand the underlying layer than become a framework specialist."
That I can understand. I mean, in the JavaScript ecosystem, a new framework pops up every 6 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 1? 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 would 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 slice bread but it’s nicely designed and is 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 don’t overspend. Anyway, should I have time left, I would prefer to increase my test coverage, run some some mutation testing or refactor that part I’m not very proud of.
Refusing to reuse even has a name in software engineering, the NIH syndrom. 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 an tangles 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, 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 developed, even though it’s not documented, not tested and a solid Open Source framework does the same and his 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 of a couple of 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 works… 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, you were not curious enough to understand what happened under the cover.
But you have to stop somewhere. Software development has an 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 personally 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 his opinion: try using frameworks and the opposite, 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.