Bulldozer coding

Jaroslav Tulach, designer of NetBeans API, defines the bulldozer coding as  instead of designing elegant solutions to problems at hand, you choose to use heavy libraries which are good for manythings in "Practical API Design". Which kind of reminds me of the Developer Jar Ratio that I wrote here.

Up side of the aproach is you are supposedly getting things done more quickly therefore increased productivity.

Apparent downside is that increased system resources needed for the application. The answer to that is buying memmory is cheaper than the developers time.

This approach apperntly works but still I don't think it is acceptable. My personel experience is that while you should use cluster of servers for your application you should also need powerful machines for your developers in order to get the developement time benefit. For example checking the hibernate forums lots of junior developers find out that they needed to extend "permanent heap size" the hard way. Again even with a powerful machine and hot deployment enabled server you will be restarting your machine a lot which is the faster the better. If you are using an api like hibernate which generates classes to do their trick and jvm with a permanent heap space, the more you restart your machine the more classes will be left in your memmory which means buy more RAM. The funny thing is as this is a developement problem it can be thoughted to be ignored.

Developer JAR Ratio Hypothesis

Ever felt like you are dealing with 3rd party jars and library's more than you have to ? They may make things easy but they come with a lot to know and nasty bugs that you have to track down. I believe making the decision of using a 3rd party jar, or building the solution yourself is not an easy one. 

On the one side of the problem is you don't want to reinvent the wheel and use the established solutions. On the other hand those libraries comes with lots of features that you don't really need, they may be well tested but still you will probably run into some hard to tackle problems and bugs, for the last the development team would have to learn to use the library properly. 

Adding a new jar to the classpath should be carefully thought based on, how much you already know the library, will it be a overkill to add the library or are you shooting birds with rockets, make sure you are not just using because it’s a popular acronym, and what will it really cost me to develop right to the point solution. 

And at least my little hypothesis "while the developer per jars goes to zero the more complex and unmanageable becomes your project".