Closures, builders, constructs such as these can save you some time, once you learn groovy. 

How much time is debatable, because I don't type a lot even when I'm writing Java. Once I define something in Java it's two characters and control space in the IDE, I never type it again. I don't even type it the first time, usually everything is just named a close variation of the class name, which the IDE does for me, with control-space. But already I digress. 

Seth Godin: Quieting the Lizard Brain from 99% on Vimeo.

Seth Godwin normally poses as a marketing guru, which makes this video an odd duck for the software developer. 

If you want the abridged version: "Ignore all the normal excuses. Set a date, and ship your software. The world needs it."

You may or may not agree with the conclusion, but he does a great job of busting through the noise and identifying how a culture of excuses and passive aggressive players can keep a development organization from succeeding.

Is there a conclusive argument for or against TDD or Test Driven Development?

One Example: Bug 1109

I just closed bug 1109 after 5 weeks of working on it, little bit at a time between other more serious issues.

It fixed in one line of code. I've probably got a dozen or more hours in it. It was pretty obvious, when I found it, but it took me at least12 hours, maybe more, of searching to find it.

Where Does OSGI fit into Your Daily Routine?

If you're an enterprise Java programmer like myself, you've probably had moments when you wish you could just put up your own web application on a Tomcat somewhere.

This is the second weekend this year that I got this page going to a jboss site. Last time it was for days. So far, this time, it's almost 24 hours.

This is a company whose primary product is reliable server software. How reliable does it look when their own site goes down for hours, days at a time?

From the "Sad State of Software Design Department" this article which I picked up off of slashdot 

Bottom line (my interpretation)

1. Tail Wags Dog - The software didn't help.
2. It could have - maybe.
3. Crappy Design trumps all other concerns.
4. No mention of gold standards for design.
5. You can pick your conclusion - including "Don't Computerize Medical Records"

Situation Normal: No-one learns from Steve Jobs

I've been trying to teach myself how to create videos from [java, brms] user group presentations for over a year now, and it's mostly been a failure despite some tremendously successful efforts. Only recently have I learned enough to make it a success, and even now I can't actually succeed, I just know how I might succeed if I wanted to invest even more effort.

Summary:

Making simplicity complex, for fun and profit: Roger Sessions makes his next move.

You might think you're reading the Drudge Report on software, with MIT grad students doing the numerical analysis. It's a superb job of mixing fear-mongering with obnosis and fancy formulas. Pages later, you'll come to the conclusion that things are too complex, and that you can hire Roger Sessions to show you how to make things simple.

Just got sent this link about a new software product

http://www.scrumd.com/tour

The best feature ? 10 second demos ! No kidding, several of them.

Information Overload Dictates:

... I don't read or watch anything that takes more than a few seconds. There's just too much out there.

What really cracks me up is when companies send me 1 hour webinar links. As if I'm going to take an hour to watch a webinar about a software product ? On YOUR schedule, not mine ? Are you kidding ?