- TREVOR HINSON -
If you are looking for a different approach to complex software, web and mobile solution delivery then let's talk.
ABOUT
SOFTWARE
WORK WITH ME
SOLUTIONS
COMMUNITY
Reducing Future Project Costs ...A typical enterprise Java software project, unless it is developed by people who were dedicated to the task at hand and actually knew what they were doing, can end up as a bundle of competing technologies, libraries, components. A massive blob. J2EE tends to lead you down this path also because a lot of the time everything sits within one JVM space. The thought process seems to be along the lines of ... it is just hard disk space so why should it matter. Unfortunately this could not be further from the truth. It may not matter at that particular minute but that does not make it right.What This Actually MeansThe easiest way to explain this is to think about another industry. Take the engine of a car. If typical software development dependency management was applied to the car engine then you would have multiple competing parts all in the same engine. For example, think of a car engine with multiple radiators but they are all doing the same job. Random pistons left in the side, not actually doing anything apart from interfering with the running of the engine. How about four exhausts systems, one of which is plugged in, two others just incase because someone thought they would be needed and the other attached into another part of the engine all together because a different mechanic preferred the type of exhaust. This is how a lot of enterprise software is made, particularly in the Java space. In essence it does show a level of immaturity still in the industry and a lack of professionalism. The problem is that with a car engine you have a physical item which, if you know what you are doing, you can obviously see is incorrect. In the software domain things are not as easy to identify. Some Examples ...I found in one project with the full application server libraries (jar files) bundled with the business logic libraries and yet the code was running in a completely different application server all together. Another example was the use of the Spring core, inversion of control, libraries being used at runtime for dependency injection within an ATG project. Others include enterprise vendor JMS messaging libraries being directly part of an otherwise very good XForm implementation. Or many different versions and ways of parsing XML. The list goes on. With Test Driven Development there is now more of an emphasis on enhancing the quality of a solution right from the start through unit testing and other techniques yet dependency management seems to fall by the way side. Another Time Based Cost ...Apart from the potential issues you are exposing your project to in the future there is also the fact that new team members will find things more difficult to comprehend if the management of these dependencies is not carried out properly. A code base containing certain Jar files can actually suggest a completely different design to what is intended. This is particularly an issue if a project is distributed internationally which more and more tend to be now a days. Solutions ?Luckily with such solutions as Apache Maven things have started to get a little better. However, there is still lot of libraries that are incorrectly configured which you may source from public repositories such as Ibiblio. The Rules I Work With...1) If a library is not needed today then it is not included or even considered. 2) If a library is not needed any more then time is allocated, as a priority, to get it removed. 3) If the thought is that a library is going to be needed next week then it stays out until it is needed. (XP - YANGNI) 4) On using a public dependency repository then check what you are becoming dependent on. |
|
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
ABOUT
SOFTWARE
WORK WITH ME
SOLUTIONS
COMMUNITY
Trevor Hinson MSc BSc - On Twitter - On LinkedIn - Email trevor@trevorhinson.com
Share On - Facebook | Twitter | Digg | Stumbleupon | Google Buzz