Skip to main content

Using elephant bullets to kill small ants

Posted by felipegaucho on October 8, 2005 at 12:46 PM PDT

Few months ago we started two very similar projects in my daylight job. Both projects were WebStart applications based on simple business rules with a lot data validation and a fancy GUI requirement - almost all Swing components were used to produce the visual aspect our client had requested. Those projects shared the same life-cycle, under the same management model but with different teams. A project was carried out by a junior team while the other was formed by experienced programmers. Few weeks after the beggining, we noticed a critical difference between the projects: its sizes - both projects had a very similar number of code lines but the former was much heavier than the latter. The junior team produced their system based on third party libraries, while the experienced programmers provided a lightweight solution. Evaluating all the development process we observed a very common scene in the software industry: velocity versus reasoning. While the experienced programmers designed the software based on their solid background about the Java API, the newbies relied on Google to ask how to do their duties. Many tasks were solved through a download of a third party library. JDom, Log4J and many other JARs were dropped in the lib folder without much care concerning the impact in the project size. The tasks were quickly developed and any new issue was fixed through a new Google search. Other interesting aspect is that those libraries had also their third party dependencies, i.e., a chain reaction. You may conclude the problem was in the junior team, the people was unskilled for the project. But ask yourself how many libraries you adopted in your last project and also if all those libraries were really necessary. Few years ago people produced bank applications with less than 1Mb of memory (do you remember ambar screens?). Nowadays, any computer without 1Gb RAM seems useless for the developers. Part of this complexity comes from the user demand - friendly GUIs, robust systems to inapt users and the sophisticated technology and tools. Other aspect is about the interoperability among systems that pushes the simplicity away (SOA? EJB?). It is a natural motion in the software industry and people are not concerned about that - but there is the developers side. If one starts a simple project without thinking about its size, a system could depends on 10 Mb or more just to read mails and save files, and that's seems to be a next quality concern. When you think about software quality, do you include the size of the project in your evaluation? And what about dependencies? Ok, I'm not suggesting you to make all the hard working from the raw concepts and using only the Java API - but I feel sometimes we are loosing the sense of equilibrium in that question. My suggestion: to adopt good libraries just after comparing their features with the JRE API and also after a brief evaluation about their benefits in the project life-cycle, including the future perspectives of both projects - your project and the exogenous libraries. Let's think about that ....

Related Topics >>