|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
While many of the pundits and analysts saw Java as a fine language for building dinky little applets and little else, those who were actually struggling to build robust, distributed, object-oriented applications in heterogeneous operating environments in languages like C++ knew that it had the potential to be much more. In fact, many of us willingly struggled with the obscurities (and even the bugs) of the early versions of Java in a attempt to plumb its depths and prove its worth in the enterprise.
Over the last eighteen months or so, I've noticed a pattern emerge. The types of projects that I've come across have all shared several interesting characteristics.
First, projects based on Java technologies have moved from small, prove-to-me-it-can-be-done efforts on the fringe of the corporate environment to a more central position within the overall IS or IT space.
Second, projects based on Java technologies now find real support and funding easily. Gone (forever, I hope) are the days of all-you-get-to-build-it-is-5,000-bucks.
Third, customers expect the resulting applications to exhibit the same level of reliability and robustness as applications written in any other language on any other platform.
This last characteristic is of particular interest to me because it validates the first two. In my experience, there is a direct relationship between how core an application is to central business processes (not to mention how much funding management is willing to provide) and how reliable the final result must be.
Therefore, if Java is going to continue its advance into the heart of the business world, Java developers must continue their relentless march toward software of higher quality.
One way to quantify such an admittedly abstract concept as software quality is to measure related concrete phenomena. An easy method is to count the number of software defects, better known as bugs.
There are two basic approaches we can take to the task of building applications that minimize the number of intrinsic defects. The first approach tries to prevent defects from being introduced and errors from occurring. The second approach tries to detect application defects after the application components are built.
The two approaches complement each other. Each brings benefits to the table, and both deserve a place in the spotlight. The first approach would ba a suitable topic for discussion in a software engineering discussion forum; since this column is a vehicle for Java technology exploration, tips and techniques, and an occasional framework or two, I will focus on the second approach, which tends to be more hands-on.