Facts about software engineering
Robert L. Glass, in 2001, authored a collection of facts about software engineering titled Frequently Forgotten Fundamental Facts about Software Engineering. Glass wrote:
I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination!
In that spirit, I have selected one each of my favorite requirement and estimation facts.
RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.
Indeed, suddenly a large body of previously-unknown work is materialized, complexity increases again, and the schedule doesn’t adjust (see ES2). The knee-jerk reaction, of course, is to spend hour-after-hour and day-after-day coming up with an exhaustive list of requirements. The process can be infinitely long (see analysis paralysis) and may only reach its end by artificial means. This problem alone may be one of the strongest arguments against waterfall-style development.
ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.
Another good argument against waterfall. The risk inherent in this nearly inverse ordering is significantly reduced when software is produced in a more agile fashion. That is to say, analyzing requirements and producing estimates iteratively allows the risk to be mitigated incrementally.
Remote debugging
I never knew how good life could be — at work, mind you — until I spent some quality time with the Eclipse debugger. My days of relying solely on System.out.println() are long gone. Print debugging is only useful if you can change the code. Loggers like Log4j are only marginally better — assuming the code uses it properly in the first place.
And things get more interesting when the code is running on a different or remote machine. Luckily, Java has a great remote debugging facility. Here’s an example of how I enable remote debugging using command-line arguments.
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n
In this example, the remote application will start and run normally while listening in the background for a debugger to connect on port 8000. For further details on how to enable and configure remote debugging, see Sun’s JPDA Connection and Invocation guide.
Remote JMX
The following Java system properties allow unauthenticated and unsecured remote JMX client connections. I use these system properties when remotely troubleshooting problems during development. My JMX agent of choice is JConsole, part of the JDK.
-Dcom.sun.management.jmxremote.port=port
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
For further details on JMX and how to configure access, consult Sun’s Java JMX Management Guide.
JScience unit formatting
JScience uses Unicode characters in the String representations of some of its Units. For example, Unicode U+2103 (℃) is used to represent the unit for degrees Celsius. Those characters can cause problems with fonts and/or platforms (Windows, typically) which do not contain or recognize them. Instead, you may see a question mark, box, or other unfamiliar glyph. Here is the symbol for degrees Celsius again — ℃ — can you see it properly?
Using UnitFormat.label(), we can override the String representation to something more compatible, useful, or just different. Here’s how I changed degrees Celsius to be more compatible with my co-workers Windows systems.
UnitFormat.getInstance().label(SI.CELSIUS, "\u00B0" + "C");
And here’s how I changed knots to be represented by kts instead of the default, kn.
UnitFormat.getInstance().label(NonSI.KNOT, "kts");
Pretty XML from XOM
Getting nicely indented XML from XOM as a String is not intuitive. One might reasonably expect to try document.toXML() only to find the output lacking indentation.
Here’s how I used XOM’s Serializer and Java’s ByteArrayOutputStream to produce pretty XML.
1 2 3 4 5 | ByteArrayOutputStream out = new ByteArrayOutputStream(); Serializer serializer = new Serializer(out, "UTF-8"); serializer.setIndent(2); serializer.write(document); String xml = out.toString("UTF-8"); |
Java 6 Update 10 is available
Java 6 Update 10 (aka Java 6u10) is now available for Linux and other platforms. Sun has published release notes for this update.
I have been using 6u10 with great success since the Ubuntu 8.10 release candidate became available. Ubuntu 8.10 users can begin developing with the JDK using a couple simple commands.
aptitude install sun-java6-jdk && update-java-alternatives -s java-6-sun
Be sure to consider installing other useful Java packages, such as sun-java6-doc, along with the JDK.
aptitude search sun-java6
See how we're connected.