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 typing¹. However, static typing is a term reserved for compile-time type checking², 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.

¹Groovy 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".
²While 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: Optional Typing in Groovy

posted by Bryan at 6:11 PM | 2 Comments

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 managers¹ is to institute rules to take place of communication². 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.

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

posted by Bryan at 9:25 PM | 0 Comments