We would all like to be spending our time learning Forth or competing on TopCoder or writing compilers, but sadly we are often forced instead to work on things that will satisfy the intellectually dreary business requirements of a paying client or employer.
In those times, a developer may have the good fortune to discover a project or library that already does a lot of what they need and the question arises, should they design a whole new structure from scratch or just grab a pre-fab one?
For example, ldap. I had a project that needed to connect to and query ldap servers. I tried to interest myself in the subject, really I did. I dutifully started educating myself on the subject, which I knew nothing about previously.
My inner monologues as I did this research sounded like, “Ah, so ldap is the original nosql. That’s interesting. And it involves issues of identity and security which are inherently interesting. Okay…good…this is all really very interesting…and…and…oh God, please don’t make me learn Active Directory.” So I dedicate this paean today to the modest and useful and tedium-saving
Spring LDAP library.
For better or worse, the java ecosystem has components to help with just about every need in the enterprise world. I quickly found a few ldap libraries that looked fine. Spring LDAP had a good api, decent documentation, did not seem to overreach itself, and just worked when I tried it.
Obviously there are some risks to using third-party components. You couple your code and your understanding to the library and its api, rather than to your core subject. Sometimes, especially if you haven’t evaluated the third-party code well, the cure turns out to be worse than the cold. You’re forced to jump through hoops that you could have avoided by just doing the work yourself.
Using a free, open-source project also seems to cause developers to leave whiny, exasperated notes on the project’s forums demanding help from the volunteer project maintainers who have already saved them a huge amount of time and effort. I’m not sure how this happens but you need to guard against it.
And of course, most obviously, you’re responsible for whatever you put into your solution. If you don’t educate yourself about what you’re using and it breaks, whether it’s a Spring library or a github project, it’s on you.
Even so, if you don’t take advantage of the stuff out there, you’re doing yourself and your client a disservice. You could go back to first principles and re-imagine the whole idea of ‘ldap’, but that’s probably not what you’re being paid for. They just want something done fast. The way that the work stimulates or educates you is way down on the priority list.
You’re expected to have enough judgment to choose what can be trusted and then use it if it’s the best way to accomplish your goals. Many enterprise tasks are not only well-served by existing third-party components, they’re incredibly dull as well, so it’s a win-win.
Most developers are working on the tops of teetering stacks of tools and technologies that do a tremendous amount of work for us. It’s turtles all the way down, my friend. Some are more shaky than others, but if you do find a trustworthy turtle, there’s nothing wrong with kicking back and enjoying the ride.