Main | January 2006 »

December 28, 2005

"Safe" casting isn't safe, part 2

Many people wrote to me in response to my original post on this topic.

The common criticism was that I had excluded a third option when discussing downcasting: defensive programming.

For example, take the code from my original post and make it defensive:

object anObject = aHashtable[ USER_NAME ];
if ( anObject == null ) {
	throw new ApplicationException( "expected user in hashtable, was null" );
}
if ( anObject.GetType() != typeof(User) ) {
	throw new ApplicationException( "expected User instance in hashtable" );
}
User user = (User) anObject;
if ( user.isAuthenticated ) {
// ...

I don't like defensive programming, including pre and post-condition checking. The constant if-then-throw-exception logic obscures the intent of the code.

Compare the first example with this:

User user = (User) aHashtable[ USER_NAME ];
if ( user.isAuthenticated ) {
// ...

The second code snippet is straightfoward and clear. The first is relatively complex.

Use unit tests if you're concerned about the safety of the second example. If properly unit tested, you will have confidence that your non-defensive code works.

Posted at 05:17 PM | Permanent Link

December 23, 2005

Prediction Markets: A better way to predict project outcome

Last week's The Economist has an interesting statement on technology prediction markets:

"...Microsoft says the software giant has run a dozen or so such [prediction] markets, and that they quickly and cheaply capture employee sentiment on project deadlines or software quality more accurately than any other measure."

Google also uses prediction markets.

Prediction markets are financial exchanges where the participants purchase futures contracts that pay an amount when an event occurs. The Iowa Electronic Market (IEM), for example, allows you to buy a contract that pays out if a particular candidate wins the US presidential election. If the market price for a Bush 2004 win contract that pays that out $10 is $5, that means the market thinks it's a 50% chance. If you think Bush has better than 50% chances, you should by the contract.

The IEM's and, more recently, Tradesports.com's predictive abilities are very good. Studies have shown IEM to be more accurate than any public opinion poll, and Tradesports.com market predicted 49 of 50 states correctly in the 2004 US presidential election.

Why should this work to predict software project outcomes? There are to key factors: profit incentive and insider knowledge. Profit motive means people are much more motivated to predict the outcome accurately because their own money is on the line.

Second, and more importantly, is insider knowledge. Traditional project reporting and prediction is done by management, sometimes without the team's full input. A prediction market, however, allows rank-and-file team members -- many who know the project's status well -- to assert their opinion by trading contracts.

For example, if you know that management's expectations for delivery are overly optimistic, as is often the case, you could sell contracts that say the project will be done on time and buy futures that say it will finish late. This would lower the price of the "on time" contract and indicate to management that there is pessimism about meeting the deadline.

Another detail: the same article says that a prediction market run by O'Reilly and Yahoo! indicated in spring that Ruby on Rails and Flickr were hot technologies. Not bad!

Links:
Wikipedia on prediction markets
The Economist on technology prediction markets

Posted at 03:03 PM | Permanent Link

December 16, 2005

"Safe" casting isn't safe

C# has an operator -- as -- that has the common but Orwellian name of "safe casting:"

User user = aHashtable[ USER_NAME ] as User;
if( user.isAuthenticated ) {
// ...

I’ve worked at several places where they mandate that you use the as operator rather than the normal cast:

User user = (User) aHashtable[ USER_NAME ];
if ( user.isAuthenticated ) {
// ...

The problem is that using "safe" casting the first code snippet fails just as harshly as the second. Worse is that it fails with a NullReferenceException at some other point in the system. The example I've provided is a best case; the null reference could be used in a different method or class. Someone debugging would have to deduce that the problem occurred because of the "safe" cast.

Conversely, the second example fails clearly and cleanly with a InvalidCastException. A stack trace will point you directly to the offending line.

I strongly prefer using normal casting. It crashes early -- one of the Pragmatic Programmers’ principles.

Also, this is just one of many examples why strict coding standards generally hurt code quality more than they help.

Posted at 04:02 PM | Permanent Link

December 10, 2005

Form Follows Function

I've named this blog after the famous saying of architect Louis Sullivan.

With software, form should always follow function. Too often in my career have architectural decisions been made by applying arbitrary rules without any thought: Don't use untyped datasets, Sun recommends using EJBs, Microsoft says to put a remoting boundary between your app and the database. Pick your poison.

If software professionals would think more often about why they're introducing yet another pattern-heavy, complexity-adding layer then systems would be less complex and easier to maintain.

I guess "form follows function" is another way of saying "do the simplest possible thing that works." I wanted to mention that someone said it a hundred years ago.

Posted at 03:16 PM | Permanent Link