What is java?  Obviously we’re not talking about the warm, dark, caffeine loaded drink one buys at a coffee house.  This section reminds us that java, the language, is just that, another programming language (albeit, a very powerful one).

Java, as a programming language, has been around for a number of years. In fact, it was conceived in 1991 under the name “Oak”.  Then, it was envisioned to be a language to control consumer electronics and, through various events, including the adoption by the WWW community (most notably by Netscape in 1995) and various alliances, grew into “… a portfolio of products that are based on the power of networks and the idea that the same software should run on many different kinds of systems and devices” according to Sun’s official site on java.

Also according to Sun, "java technology readily harnesses the power of the network because it is both a programming language and a selection of specialized platforms. As such, it standardizes the development and deployment of the kind of secure, portable, reliable, and scalable applications required by the networked economy.” and, “The java programming language lets you write powerful, enterprise-worthy programs that run in the browser, from the desktop, on a server, or on a consumer device.”  A final note to the history of the java language; it is well known that it has been one of the most rapidly adopted languages ever created.

Why is all that important?  Consider the major points; java has been adopted very quickly and is very flexible and powerful.  That adds up to complexity that adds complications that, if not planned for early in the lifecycle, can lead to misunderstandings and confusion.

      Clearly we know about java, or we wouldn’t be reading this book.  However, java, like other programming languages has some common properties.

A Quick Summary of Software Properties

In the following paragraphs, general software properties are examined and correlated to five major issues that can occur during the code and test lifecycle.

What Software Is:

§       Insubstantial

§       Controllable

§       A skill

§       Loads of fun

What Software Is Not:

§       A “Dark Art”

§       A reason for delaying projects

§       An excuse for over budget projects

§       Fun to manage

It is common to see the software development portion of a venture become the scapegoat for all the trials and tribulations associated with late delivery and over budget projects.  Software developers, who take the brunt of the blame, aren’t stupid or lazy, and, if we are to assume they have received adequate design requirements, not deliberately creating the “wrong” thing.  They enjoy their craft; it’s what they do and the majority strives to do it right.  So what’s happening?

It is all too familiar to hear the tale of a programmer dutifully slogging away at his or her terminal writing line after line of code to the specifications that have been given.  There’s a time limit, the developer doesn’t have time to comment every line of code, so something that’s “obvious” is usually left unremarked and documentation may be sketchy.  That’s the first mistake.  The code is then compiled, if it compiles on the first attempt and looks to meet the requirements, off it goes to test and QA.  Second mistake. 

The tester fires it up, looks at the requirements and determines it doesn’t match or doesn’t work in one way or another.  Since the code itself seems arcane, it’s hard for the tester to say exactly why it’s wrong, just that it is.  Back it goes to the developer with an admonishment that it doesn’t work, sometimes with why it doesn’t and occasionally not. Third mistake.  The developer looks at what he or she has been told to build, looks at the testing notes and tries again.  Fourth mistake.  Changes are made and the code sent back for testing. This is the fifth, and final, fatal mistake.  Why?  Simply because the process will reiterate itself many more times than is necessary until the finished code complies and runs with what the testing team is expecting. 

Most likely, that will be when it’s late in the project schedule.  Then the blame starts with the project office being yelled at by management, who, in turn, bellow at the testers, who point the finger at the developers.  Depending on the developer, they either run back to their cube for more cold pizza, warm cola and late nights or, design new levels for their favorite first person shooter game (probably involving the project office) or, start looking for a new job.  As stated above, managing software projects is anything but fun.

It is probable that a good number of you reading this book have either seen or had this happen on your projects.  If you haven’t, you either haven’t had a lot of experience with software development projects, yet, have been extremely lucky, or already benefited from the some of tricks, tips and techniques this book will endeavor to make clear.

In the generalized (and java specific) approaches described in this book, we attempt to demystify the art and craft of java debugging and testing, reduce cycle times and, if not exactly making java project management fun, it should be more bearable.  The remainder of this book details the above five missteps, what they are and how to avoid (or at least limit) their impact to a java development project.

      We’ve discussed java and general software properties, now let’s examine a bit about debugging and testing in general.

Java Testing and Debugging Philosophy

In general, testing and debugging have always been unpopular topics.  Although one may have been given some ideas about testing and debugging in various computer language classes, the topics are either learned from your mistakes or treated very fleetingly.  There are very few, if any, college courses dedicated to software testing and debugging as standalone subjects.  There are a number of books on the subject, but they either cover well-known languages (such as C++) or are very generalized in nature, concentrating solely on metrics.  In fact, it is recommended that the reader understand some of the general principle of test and debug techniques since this book is specific to the java language.

The last thing we want as a project team is to unleash a buggy, badly documented application on an unsuspecting user.  Unfortunately, it still happens more often than it should.  Why?  It happens for several reasons; not enough testing, not enough time for developers to clearly comment and document code, and inadequate resources allocated to the debug-test-recode cycle.  If there isn’t enough time to do it right the first time, there better be enough time to fix it.  If it becomes necessary to issue bugfix releases of an application (even on large projects) it means something wasn’t done right the first time.  It’s painful, embarrassing and lowers credibility.  Hopefully what you learn from this book will help alleviate having to work on bugfix point releases so you can concentrate on enhancements for the next big release.

There are further issues with released applications.  Someone once said, “If you write fool-proof code, they invent a better fool”.  Believe it or not, this can happen.  The good news is, there are ways to make your code closer to foolproof )or at least test for it).  There is also the issue of platform dependency; very little code targeted to a specific class of machine will run on another class of machine.  For example, device driver authors spend a lot of time adapting and changing their code as new machines become available.  Fortunately, java is, for the most part, not highly platform specific (although there are some issues that are discussed in a later chapter), which is a big plus for using it.

Many information technology professionals are aware of the value of testing and debugging, but few devote a reasonable amount of resources to implementing it.  This is likely because they believe that “their” code is either too simple to warrant the time or too complex to allow multiple paths to be tested.  Unfortunately, the former assumption gives a false sense of security, and the latter, a pretext for discounting the process.  Both of which naturally wind up producing bad applications.  Another important goal of this book is to impress upon the reader the absolute necessity to test each and every piece of code you can; the more you test, the less likely bugs are going to get out with your applications.

Overall, it is up to the project team to ensure that they do all they can, within the resource limits given, to communicate test and bug issues as quickly and concisely as possible.  Working together is the only way to diminish the appalling possibility of sending out a defective application.