Well, after using various beta versions of OmniPlan over the past two months, I can actually say a bit more about it than, well, two months ago.

For an application that's still in beta, it's very usable. In fact, I've been using it at work for project management for two months. Yes, it has crashed. Yes, there are bugs. But they keep fixing bugs, making improvements, and adding new features with each successive beta release.

They've got an AppleScript library to allow automated actions on a project plan, and plenty (10 or 12?) export options, including Microsoft Project. Without much effort, I built a custom html export template, and have been using that to publish project updates online for my team. The only things I want are extended AppleScript support (specifically to automate export to web page), and fewer / no crashes.

Over the past two months, I've sent a dozen emails to their team with feedback / bug reports, and they've actually responded to many of them. They're also taking lots of feedback in their forums. All good stuff. I'm looking forward to the official, non-beta launch of OmniPlan.

I just read Good Agile, Bad Agile from Stevey's Blog Rants. Don't know much about him, but he was a developer at Amazon way back, and now works at Google. It's a long post, and really hit home on a few particular areas of software development.

Excerpt #1 about how most companies approach software development:

• hire a bunch of engineers, then hire more.
  
• dream up a project.
  
• set a date for when they want it launched.
  
• put some engineers on it.
  
• whip them until they're either dead or it's launched. or both.
  
• throw a cheap-ass pathetic little party, maybe. This step is optional.
  
• then start over.

Ouch. I wish it weren't so easy to cite several great examples of this from my own personal experience.

Favorite excerpt #2 about the laws of marketing:

• anything that calls itself a "Methodology" is stupid, on general principle.
  
• anything that requires "evangelists" and offers seminars, exists soley for the purpose of making money.
  
• anything that never mentions any competition or alternatives is dubiously self-serving.
  
• anything that does diagrams with hand-wavy math is stupid, on general principle.
  

  And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."

I'm starting to really like this guy. This fits nicely with one of my long-held beliefs about products and business: if something is touted as being Really Good but requires a long explanation to prove it, it's safe to assume "Stupid and Bad".

He goes on to talk about specific things Google does to take care of their people - and not just developers, but all of their people. They basically give them everything they need to do their jobs, whatever it is, as well as awesome rewards for doing great work, huge incentives for spending time on things that matter. And "things that matter" does not mean "things that someone gathers metrics about", or "hitting a date".

You cannot put a label or metric on individual little tasks for a developer. Instead, software development is a big moving target that cannot be pinned down. You know when you've hit it (or not), but you cannot tell before-hand what you'll need to do in order to get there. And trying to give incentives based on your provably-incorrect predictions of getting there is a big mistake. You will be wrong, your team will not get "the prize", they'll feel like asses for trusting you, and they'll be a lot less likely to believe you the next time around. Nice. Rinse and repeat a few times, and it won't be long before the team has lost all respect for the leadership. What a way to run a software group.

So given Google's committment to truly taking care of everyone, and going out of their way to address all areas where people could possibly complain about anything, they have created an extremely productive, self-managed group of people who do the right thing without management. People work quickly, projects run smoothly, the results are good, and employees are happy about it.

Excerpt #3, which makes a job at Google sound very attractive:

This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on. You don't need "war team meetings," and you don't need status reports. You don't need them because people are already incented to do the right things and to work together well.

I've been playing around with Ruby, and I like it. Ruby is powerful and simple. I haven't spent much time figuring out how to get the language to do what I want like I would with Java. Instead, I just do what I'm trying to do, without focusing so much on how.

For example, if I want to build lists of a custom objects, and allow sorting and filtering, I only add one simple method to my object definition to get a ton of cool comparison behavior for free. In Java, I have to do a lot more work, and the results aren't as good, or maybe I decide against proper code organization in Java in favor of some gross, hacky solution that's quick and dirty.

So it's interesting to hear people defend Java. "Oh come on, Java's not that bad", "you're just a Ruby zealot!", "I can do all of that in Java", blah blah blah. To an extent, those comments are correct. But what do they really mean?

"Oh come on, Java's not that bad"
Fine. I'll agree that Java is not that bad. But take this argument a little further. We can build a world-class application in C, Lisp, or Haskell almost as easily as Java. There are plenty of rich libraries of functionality that we can leverage in other languages, so we're not going to 'reinvent the wheel' as is often hyped with OO languages like Java. In reality, the language choice doesn't matter that much. It's not like software development didn't exist before Java. I know several viable software shops here in Austin that are using languages other than Java (including C++, Ruby, Php, Python, ...). The attitude of "software can only be done in Java" is just silly. The heart of this comment is really a posture of defensiveness. I don't care if you say your tools are better than mine, I like Java just fine, I'm not gonna change, you leave me alone!

"You're just a Ruby zealot!"
Say that I am in fact a zealot, I can't shut up about how great Ruby is, I'm sooo excited about the language. Say all of that is true (it mostly is). Here's the big question: what the hell is wrong with that? As long as the language will handle the technical requirements of the project, it's great for the developer to be excited about the tools, excited about building the software, excited about how much he loves doing his work. Java is not exciting. It's big, fat, and bloated. Being a zealot is not a bad thing, and is often quite powerful. You should be happy that your team is excited about doing work on the basis of the tools alone. Happy developers = Good work = Successful company.

Of course, there are practical realities that cannot be ignored - the team may not know Ruby (or whatever language / tool is on the table), there might be a large, pre-existing code base, business demands may prevent the ramp-up to use a new language. All of that stuff is valid, and may very well trump the excited zealotry of the team over Ruby. That's a trade-off you have to make. Happy, excited, forward progress vs. business needs, collective team knowledge. No right answer for everyone, but it's definitely not bad to have zealots. In fact, you should probably always have a few, otherwise you'll be driven by your marketing people or stupid articles about business trends. I don't care how many shops are using Java, it still might not be the right choice for our group. The number one language in terms of lines of code on the entire planet is Cobol (thank you, military), but that means nothing for my software group. Without a zealot among you, you're likely to end up being another sheep in the flock, doing what everyone else is doing. That's bad. This is exactly what Dave Thomas was talking about in his keynote address at NFJS earlier this year. Angry monkeys, indeed.

"I can do all of that in Java"
I'm sure you can, but that's not the point. Think of any task you do in a day (at home, at work, where ever), and consider how many different ways you could achieve the same result. I'm sure you can think of several options. But which one do you choose? The fastest, simplest way to get the correct results. It's an almost unavoidable aspect of human nature - we tend toward the shortest path, and that tendency grows stronger with increases in stress or pressure. In a work context, this means people will favor "getting it finished" over "doing it correctly". Happens all the time in software. TODO: fix this! it's gross and inefficient, need more time to do it right! This is exactly why we have "best practices" in software, and simultaneously why almost nobody follows those practices.

So after I've built something in Ruby, and you've built it in Java, I'll have moved on to think about adding new features, and you'll be reading through javadoc about which package to use, or how to work within Java's linguistic constraints to do what I've already done in Ruby. In the end, we'll both have code that achieves the same result, but mine will be shorter and simpler, and therefore easier to understand, maintain, and extend. And I'll have had an easier time building new stuff because my head was less involved with "Ruby" and more involved with my problem domain, so it will take less mental effort to make more forward progress.

If you've ever written a unix command line script, you know it has to start with #! followed by a path to an executable. For shell scripts, you'll specify the path to the shell in which you want your script to run, like: #!/bin/sh for Bourne shell, or #!/usr/bin/perl for Perl.

I used to use vi to help me out with :r!which sh. So when you type :r!which sh in your vi window, you'll see the evaluated result in your editor (namely, "/bin/sh"). Not bad, and makes it easy to handle updates when scripts move to different machines.

But here's a nice shortcut:

#!/usr/bin/env sh, or
#!/usr/bin/env ruby, or
#!/usr/bin/env perl

So now I only have to remember one path (/usr/bin/env), my scripts just got more portable across different machines, and are no longer tied to path constraints in my local shell.