Shades of Grey
Dynamic typing or Strong Typing - choose one. Collective code ownership or a single owner of a class - discuss.
You've seen the scene many times in court room dramas. The prosecuting attorney sneers at the witness and asks an ambiguous question and insists the witness answer yes or no. The audience knows that without qualification neither answer is quite correct and yet we do the same thing in our every day life. As programmers we are asked "which is better, a rich client or a browser-based application". After you patiently outline the benefits and limitations of each approach, the questioner says something like, "o.k., but which is better."
I thought of Glenn Vanderburg's blog Six of One, a Half Dozen of the Other after reading the Borland piece on FDD and class ownership. There are many issues with two sides that may be appropriate in different settings. Glenn writes "I frequently encounter blogs, articles, or mailing list postings from people who believe dynamic typing is the one true way (I've been guilty of such things myself, in fact). And then I turn around and see people claiming that strong static typing has undeniable benefits, and it's just too hard to build reliable software in dynamically typed languages (ignoring the numerous counterexamples), etc., etc. And the thing is ... I don't think either side is entirely right or entirely wrong."
He presents a list of these dualities that people tend to come down strongly on one side or the other:
- Functional vs. OO (Anton's koan is just one example of this).
- Compiled vs. interpreted languages.
- File-based source code vs. live images.
- Relational vs. OO databases.
- Tests as design tools vs. tests as quality tools.
- Browser-based apps vs. rich clients.
- Code as data vs. rich syntax.
Also in Java TodayMartin Fowler thinks through the issues of using Specification by Example in contrast to Design by Contract. He concludes that because " Examples only highlight a few points, [..] Specification By Example can't be the only requirements technique you use, but it doesn't mean that it can't take a leading role." Fowler points out that one of the lies of the XP community is "Once and Only Once, but in fact they always say things twice: once in the code and once in the tests. Kent has pointed out that this double-check principle is a vital principle, and it's certainly one that humans use all the time. The value of the double check is very much tied into using different methods for each side of the double check. Combining Specification By Example with production code means that you have both things said quite differently, which increases their ability to find errors."
While Agile methods advocate collective code ownership, David J. Anderson writes about The Case for Class Ownership in the latest Coad letter. "Feature Driven Development (FDD) [Coad 1999, Palmer 2002] believes in class ownership - the notion that a single named developer (and perhaps a secondary deputy) is selected to 'own' a class. Only that developer will write code in that class. [...] Class ownership requires discipline, teamwork and a little forethought and planning by Chief Programmers to make it work. Class ownership delivers class level component architecture integrity at the potential expense of smooth flow of coding."
In today's Weblogs , Daniel Brookshier blogs about Killer Applications and JXTA. The feedback cleared up some questions I had about how JXTA works as Daniel responds to a question by explaining "A JXTA network consists of machines inside the firewall and in the wilds of the Internet. It is the few machines that are connectable on the outside that enable most peers to operate. These Internet based boxes which normally have a fixed IP address are proxies between computers.
The cool thing is that these computers can handle a lot of traffic with low impact to resources. They are in fact acting just like networking equipment - only in a JXTA network.
Many companies and individuals have volunteered these computers. There are more than enough for current network needs. I fully expect more companies and ISP's to jump in because they can improve performance and security."
In today's Projects and Communities , Today's edition of Java Live is a chat with Ian Formanek, NetBeans' chief of technology and senior product manager, Larry Baron on "What's New and Cool in NetBeans?" Join in Tuesday, March 30, 2004 between 11am and noon PST.
In today's java.net News Headlines
- IBM Releases Seven Tools for Java and XML on Unix
- IBM Rewriting Rational for Eclipse
- PeaPod Lightweight Container Initial Release
- OpenWFE 1.0.0
- jTDS JDBC Driver 0.8-rc1
- JFreeChart 0.9.17
Registered users can submit news items for the
href="http://today.java.net/today/news/">java.net News Page using
our news submission
form. All submissions go through an editorial review by news director
Steve Mallet before being posted to the site. You can also subscribe to
News RSS feed.
Current and upcoming
- March 30 Chat on what's new and cool in NetBeans
- April 16-18 Penguicon 2.0
- April 16-18 Wisconsin Java Software Symposium
- April 20-21 Sun Tech Days: Singapore
- April 23-25 New England Software Symposium
- April 30 - May 2 Twin Cities Software Symposium
- May 6-8 The ServerSide Java Symposium
- May 8 Kwarup do DFJUG
- May 10-14 JAX 2004
Registered users can submit event listings for the
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e"> events submission
form. All submissions go through an editorial review before being
posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the
Today RSS feed. All java.net members can subscribe to the email
updates for the site at the href="https://java-net.dev.java.net/servlets/ProjectMailingListList">
java-net Mailing Lists page. You must be logged in to subscribe
to the javanet_Daily and javanet_Weekly lists. Also, once this page
is no longer featured as the front page of
java.net it will be archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.