First thoughts on Ruby...

Thank god blocks are back.

What the hell is up with all the special characters and weird syntaxes? Feels like C's question mark colon is coming back.
Why do people always think having multiple ways to do the same thing is a good idea?
Mixins are good because ...
Parser errors remind me of the LValue errors I used to get out of Microsoft C compiler.

Maybe static typing is good for code generation as it allows code completion and easier refactoring. (Did Ted really say that???)

Ruby on rails looks more like a steam train than a modern locomotive. Better than what we have, but not environmentally friendly.

Most importantly:

I've only used it for a couple of days. Ask me in a week.

A cripple without a cane...

I'm doing a little work in Ruby. There are no refactoring tools or code completion.

The burn down to zero

One of the things our project is missing is the excitement of completing what we think we can complete. Our executive team has declared that 60 stories a sprint is the goal for the team. Currently we're running at about 42.

Unfortunately, this means that the teams always feel that they are behind. There is no victory in completing all your stories, or even better if we did 50, we would still be behind. I think tomorrow we should pull 18 low priority stories off the wall. We can give our team a victory. They are a great team.

Dammit a good article...

.. by Alistair Cockburn. When this guy is on, he writes really, really well.

http://alistair.cockburn.us/crystal/articles/aih/areiterationshazardous.htm

Good example of not getting caught up in the hype of XP. Remain focused on the end goal and make your development process work around that. Don't make the process the end goal.

Some problem solving strategies...

When I'm trying to solve a hard problem, refactoring or otherwise I employ some strategies to help me get a better understanding and arrive at a good solution.

First I come up with a number of ideas. Very explicit different approaches to the problem. Stupid ideas are as welcome as ones I think are excellent. They make you think about the problem in different ways. I then cross ideas off the list that clearly are way too much work or won't work at all.

Of the ones that remain I'll choose two that look promising. If there is one that looks promising, but I don't like, I'll often try that one first. It might lead to new understanding. A spike of 1 - 2 hours will lead to new learnings and new strategies.

Sometimes, when I grow too attached to an idea, I'll hand the problem to someone else. I get enamoured with my own ideas, and this is a bad thing. By passing control to someone else I can be assured additional ideas will be generated and heard by the person working on the problem.

Is this double speak?

http://www.amazon.com/exec/obidos/tg/detail/-/0596008740/002-0408435-3356841

A leadership role for software team leads

On software development projects there can be lots of turmoil. We live in a time where programs can be extremely complex and difficult to estimate. This creates stress for business people who are trying to evaluate return on investment. Unfortunately, we cannot give guarantees - the technology doesn't allow it yet. This creates justifiable stress among the business people and turmoil on the team.

Software leaders have a different role to play than most other leaders. Yes, you're responsible for encouraging innovation, encouraging thinking about the problem differently to find newer and better ways to build things. The different thing in software development is that you're reponsible for protecting your team.

This means, you have to ride out turmoil and explain (not hide) it to your team members. Unreasonable demands from the business group must be tempered by your explanations and reasonable expectations. Unreasonable expectations from the business group must be fought visibly by you.

Above all you must be honest and not play games. Your integrity will serve you well.

Leadership is hard work everyday.