Once upon a time, programmers had a mantra which went "if it was hard to write, it should be hard to understand". Said mantra was used to justify the sloppy programming practice of not commenting your code. This "enlightened" behavior made it difficult when even the original author went back to update their own code a few months later (and I won't even discuss the chaos and confusion that ensued whenever some poor soul, who did not write the code, ever had to go through it to make updates). The ultimate goal of the "zero documentation" approach was to ensure job security. If you were the only one who could understand some arcane application that was mission-critical, then you were indispensable.
Today, we ran into Java's Spring Framework.
Now, for those who don't know, a framework is a structured approach to abstracting general elements of an application in development and they can range from a set of guiding principles (such as MVC) to a full set of programming tools (like Hibernate or Spring). However, after looking through the code, we decided that Spring seems to be nothing more than a product of the old programmer's job security approach coupled with years of evolution.
Of course, we're engineers so, in an effort to make sure that we weren't missing anything -- especially the obvious -- we were "off to the cloud" to see what could be learned about this new adversary.
The first stop wound up being our last. Right there, about halfway through the first page, we saw a gem that not only summed it all up for us, but let us know that our initial thoughts were correct.
"The Spring Framework is the only framework available in Java which offers managed data access environments outside of an application server or container." - Wikipedia page on the Java Spring Framework
That's like saying Microsoft Windows is the only operating system that provides the blue screen of death when the kernel encounters a fatal error.
