Saturday, February 27, 2010

Moving

Because Blogger is discontinuing FTP service, my blog is moving to http://blog.scruffles.net

Tuesday, April 14, 2009

Optional Typing in Groovy

Groovy has a feature called optional typing which allows types to be declared for fields, parameters and method return values despite Groovy being an otherwise dynamically typed language. This is a useful feature if for no other reason, than for interacting with statically typed languages such as Java. When Java calls Groovy code, it won't have to cast everything to its real type to use it.

While the feature itself is useful, the name optional typing, and how the feature is marketed is confusing and misleading. Many assume the phrase optional typing is short for optional static typing1. However, static typing is a term reserved for compile-time type checking2, and Groovy does none of that. This will actually compile (but not run) in Groovy:

int x = "I am not an int!"

I think the term optional typing should be abandoned and the books should be updated to be a little more honest. Programming is difficult enough without having to fight mis-information.

1Groovy In Action specifically states this to be the case, with two pages of text on how to choose between dynamic and static types when writing Groovy programs: "The choice between static and dynamic typing is one of the key benefits of Groovy".
2While wikipedia is never a definitive source, it states nicely that "A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time." It also provides some good references for those who would like a more definitive source of information.

Labels:

Friday, April 3, 2009

Managing By Metrics

People who work with me are probably getting sick of hearing my rant on managing by metrics. In a nutshell, I find that technical leaders have a tendency to be anti-social (a trait typical, if not slightly less damaging, in their previous career as developers). The path of least resistance for these anti-social managers1 is to institute rules to take place of communication2. Rather than pairing with a developer for an hour or floating from project to project to get a grasp on capabilities and direction, the antisocial manager prefers metrics dealing with code coverage, defect rates and test failure rates.

I only bring this up now, because I heard an interesting story on NPR that I thought paralleled my problems with managing by metrics. All Things Considered compares the struggles the NBA has had with player pay incentives with those on Wall Street. In both cases, employees were given bonuses for reaching individual goals. In both cases, those individual achievements can have a negative impact on the team as a whole. The individual is encouraged to act in the best interest of themselves over the short term to the determent to the larger organization. In essence, people are making bad decisions, because we pay them extra if they do.

Then later, they wonder why
a) the star of the team breaks a scoring record, but the team doesn't make the playoffs
b) the project has great code coverage, but very fragile code
c) your company did so bad it helped drive the entire economy into the crapper, yet your employees somehow earned $270 million in bonuses.

1 the phrase anti-social manager should be an oxymoron
2 Ironically, this is the exact opposite of the first statement in the Agile Manifesto: Individuals and interactions over processes and tools

Thursday, February 5, 2009

Whenever I start learning about a new language on the JVM, I always find myself wanting to sprinkle the new language into my Java code. I never want to be the guy asking to scrap our project and start over in Groovy or Scala. I'd rather just drop down to Groovy to parse some XML, or write a quick Unit Test for my Java code with Scala.

The problem I run into, is that adding code from another language always either involves altering the build process to compile the other language, or adding lots of boilerplate code to interpret an external script. I really don't like either solution.

I think if Sun is going to push multiple languages on the JVM, the first thing they should work on is natural integration with those language from Java.

One solution that would be interesting is similar to GWT's JSNI. In JSNI, you include your Javascript as a comment on a native method. Rather than linking to a native library, the GWT compiler digs the javascript out and includes it in the generated Javascript. Calling code can consider it to be just another Java method:

public static native void alert(String msg) /*-{
$wnd.alert(msg);
}-*/;


I'm not really fond of putting the code in comments. I think that part is just a work around so Google could add the feature without breaking compatibility with IDEs and tools. Something like this might be a little cleaner:

@script(language="javascript")
public static void alert(String msg) {
$wnd.alert(msg);

}


This would be a language change to Java, of course... but I think it would be worth any extra effort. It would allow developers to use the best tool for the job at a much more granular level.

The Java compiler could just shovel the contents of the method into a JSR223 eval block without much thought. In time, other compilers, such as Scala's could be aware of this syntax and could compile the code.

There are other ways to provide support for integrating languages cleanly. Here's a great presentation on C# 4 and how its support for dynamic types will help it integrate with other languages (here's an ipod version for those who don't want to mess with Silverlight). I would never expect Java to move forward this aggressively, so I won't bother go into the details. But it's a good presentation for those who like to daydream.

Saturday, January 24, 2009

Video Browsing by direct manipulation

This is just cool.



and the explanation:

Monday, October 13, 2008

Dogma in Programming

One of the more harmful trends the programming industry is the tendency of programmers to create dogma to define good programming. I believe there is a basic laziness in people encouraging us to boil down a chapter of thought provoking rational into a bumper sticker or a tag line: "Goto Considered Harmful". In addition to laziness, I think this trend is enforced by a system that ensures that most programmers start with a solid foundation in math, science or engineering - fields of study with provable right and wrong answers to just about everything. I think this conflict leaves a lot of developers in limbo, unable to make forward progress because they will never accept programming as a craft.

Good resources for programmers are everywhere. Books like Effective Java, The Pragmatic Programmer and Clean Code seem like an echo chamber of good programming practices. With the growing popularity of Agile methodologies and test driven development, there is no shortage of resources on how to write good code... from the concept to delivery. But no matter how careful an author is when writing their advice, it will always be taken out of context. I suspect that is the case more in our industry than most due to the relative immaturity of our craft.

Everyone knows a programmer who quotes books, and doesn't understand the meaning behind them. Someone who insists on consistency at the cost of maintainability (hmmm.. why did I want consistency again?). Someone who quotes 'You aren't going to need it' back to a customer advocate who is asking for a new feature. Sometimes context is everything. Sometimes concepts are more important than rules.

Another common type of programmer I've seen a lot will read a great book like Agile Principles and try to turn its practices into laws. Once they identify two seeming conflicting 'laws' or find a rule that conflicts with the reality of their workplace, they stop in their tracks... unable to move forward. "This stuff doesn't work! It doesn't deal with this situation!" Of course all the principles still stand and would apply with a little flexibility, but doing so would require admitting that programmers are more craftsmen than engineers.

Obviously the entire industry doesn't work this way, and the abilities of the typical developer vary greatly between regions, industries and even employers. From time to time, I catch even catch myself over-generalizing things1. At those times I like to recite my rule: "Dogma in programming is always bad".2

1 Several times, just while writing this
2 Yes, it's meant to be ironic. Its a play on one of my favorite quotes: "All extremists should be shot"

Wednesday, September 17, 2008

Agile and Geomery

In geometry we have the pathogen theorem: if you know the length of any two sides of a triangle, then the third is fixed. I think this makes a great metaphor for the primary advantage of using Agile:

Software projects have three variables as well: resources, time and features. If you know two, you can no longer negotiate the third. Resources are almost always fixed, which leaves two variables. Agile forces you to choose a fixed timeline and encourages you to let the features reveal themselves. Waterfall assumes resources and features are fixed, and leaves the deadline for you to discover as the project marches on.