In the era of the almighty frameworks and reusable APIs, we are now in a position where applications can be put together quickly. This is awesome for people bootstrapping companies or anyone in general who needs to get a functional application up soon. My question and fear is what does it do to our understanding of the core elements of the system? Sure, we can run to the documentation or get a patch if one of the application layers beneath ours breaks, but wouldn't it be good to understand how things worked to some detail?
Welcome to the world of “Hello World on Steroids.” The era in which some programmers have become systems integrators and are merely just moving data: Read from a queue, do some simple data manipulation, write to the database, then write to a reply queue and repeat this pattern for all other applications. Not to knock systems integrators (systems communicating is necessary), but if this is all your doing, you may be effectively losing the ability to write algorithms and solve problems (I speak partially for myself here as I was experiencing this for awhile and still am to some degree; I know a lot of you out there are in the same boat.) The frameworks and APIs available are powerful and all encompassing, take Apache CXF for instance. This is a pretty powerful framework offering a lot out of the box:
- Multi-transport support: HTTP, JMS, TCP/IP, etc
- Various protocols support: SOAP, RESTful messaging, XML, CORBA, JSON, WSDL, etc
Apache CXF has a lot more features than this but with this short list you can kind of get a feel for some of the capabilities it possesses. This framework alone does not rob anyone of problem solving ability but the APIs that come with the core Java language and all the free stuff out there may. You will probably be writing nothing more than POJOs with getter and setters wrapping the real APIs doing all the heavy-lifting. Want to connect to the database reliably and manage connection pools? Use Spring and Apache DBCP. Want to serialize an object to XML and deserialize XML to an object? Use JAXB. Want to create a tree structure or hash for some data structure you are creating? Use Java's Collections framework. If you are in an organization that has a lot of stuff built in-house that you have to use, the same applies to you – most of the work done for us out of the box. All we have to do now is design and put things together like Lego blocks. Therefore, the hard thinking is done for us by a generous bunch of geeks. So are we becoming mere dot-getters and dot-setters?
These frameworks and APIs are great or so you may think, and I agree at some levels, but how does this stuff work? How do you use it properly if you do not understand or cannot write one yourself? What happens if it breaks in production? Do you stare at the stack trace in fear and run to the closest browser for your coding ally and team-mate Google? This is a dangerous position to be in as a developer and effectively dumbs us down over time if we are not doing anything challenging. Some of you may be saying: “Ok I get what your saying, but this stuff is open source and I can see and learn from the code, isn't that enough? Documentation for a lot of these tools rock as well so I do not need to know anything at all. Also buddy, the web community out there is supportive and someone will have the answer on Stack Overflow or some other site no?” First question: It may well be enough but I contend that a lot people may shy away from getting the source and learning from it. To the second question: these communities are awesome and a God-send; yes we cannot know everything and it is more productive to ask instead of wasting time thinking about what went wrong but if you do not think at all your in for serious trouble in the long run.
Fundamentals should be covered in detail and well understood. Whether it is covering these things extensively in college or on your own, you should know at least how data structures work. As a developer, you should have some core knowledge of algorithms and framework development to begin to understand what may have been the design decisions of the team building the frameworks you use, the choices they may have made while building it, how they may have built it, advantages and disadvantages the framework may have, and this may be the best part: potentially extending it and/or contributing to it. If you are contributing to a framework and/or API this is a good sign that you are on the right track and probably passionate about the field. This to me is also a sign that you may possess adequate knowledge in the area. If this is the case for you, then this article is a moot point to gloss over and ignore. For the others out there who are not in this subset and belong to the dot-getters and dot-setters club be warned: Go beyond just putting applications together as Lego blocks and try to get some depth in some area.
To end this I would like to say, I strongly agree and support the notion of Lego application building and reuse as much and as often as possible. There is no point in reinventing the wheel over and over again when problems have been solved efficiently by people with expertise in niche areas of the field. My problem is when developers make no effort to understand the plumbings of what it is they will be using and are just happy making API calls to get the work done. I think this is a dangerous approach to take and just waters-down what we do for a living and takes some of the greatness out of it.
Follow me on Twitter mrosario2012
