Jacob's Garden

Felt it was in my way...

But I'm not... givin in an inch and you might Wondddeeerr whyyy.... I feel like letting my FREAK FLAG FLY!!!!

Well, okay, I gave in and chopped off the hair.

This one really got my goat today...

I was trying to figure out why file_transfer wasn't sending the headers I was passing in after upgrading my module from D6 to D7.

Turns out that the function signature for the function which sends headers had changed, and decided that instead of taking a serial array, it now takes an associative array.  That's fine and all, but it did something I see commonly in Drupal which makes my blood boil.

It does nothing.

No error, no warning, nothing.  In fact, the function drupal_add_http_header($name, $value) actually returns you a list of headers already added if you don't pass in the name.  Imagine all the disk space saved by not creating a function called drupal_get_http_headers! errr....

http://drupal.org/node/732486

Ever since Google announced that you could upload arbitrary files to google docs there have been a bunch of shakeups in this market.  The profits of companies like https://www.dropbox.com are obviously threatened by this announcement.

Sadly, The big G didn't announce that it was providing a rich desktop app for drag-and-drop uploads, synch, etc.

A company called Memeo did.  I did some evaluation today, and I really love this app.

Their pricing is really attractive (just $9 /head per year).  However, I think their only hope of long term survival is a Google buy-out and somehow, I just don't see that happening as they Google will likely do something fuse based and/or build it in HTML 5 and just wait for the masses to catch up / drive the browser market.  Another open source solution I looked at but couldn't get working in 30seconds on my mac is http://code.google.com/p/google-docs-fs/.  It's a FUSE based implementation.  Likely not as feature rich, but nicely integrated.

Long comment from http://agilepainrelief.com/notesfromatooluser/2010/02/misuse-of-velocity-in-agile-projects.html has turned into a post here.

Scrum and Agile is something I'm particularly interested in and enthused about.  But it is strange how many people throw the terms around or even claim to work on Agile teams without a background in the reasons and common applications of Agile.  I'm not saying you have to do everything in your Agile book, but at least read one!

Some of these comments make my eyes bulge out a little bit.  I think even the most elementary book on scrum makes it really clear why we use story points and why they are the basis of all sprint planning.  

Now granted, this is *really* hard to use when you are responsible to a client and have to invoice weekly with the # of hours of work performed and estimate ahead of time what they will get for X.  Time and Materials or fixed bid, client's have expectations.  But outside of that, if you can get a client who is happy to use agile that basically means they hire X full-time people for N number of days - and hope to fullfil part of an agreed upon roadmap.

In that case, the point is that you will never have the fastest, most accurate, most consistent, perfect engineers.  However, you will always have customers - internal or external.  And the hope is that you can at least set realistic expectations with the customers which your engineers have ownership over meeting.  How do you do that?  You let your engineers estimate what they can accomplish, and you check that estimate against what they said they could do in the past.  That's what velocity is about. Not holding people accountable, but letting people hold themselves accountable.

Think of it as pacing yourself in a marathon against your average time, not trying to race others.  You can't race others because:

a). This ain't a marathon and there are a 100 finish lines

b). This ain't a marathon, more like a decathlon and some teams will excel in certain areas and flop in others.

To Sum:

Any measuring you do should be sujective, not quantitative.

Since estimation is subjective, comparing quantitatively between teams is useless.

Give smart people tools to do their job, communicate with customers and get out of the way!

You could measure estimation ability by seeing how often a team meets their targets.  But then, you are also measuring the amount of crap their customers make them deal with, company politics, internet connectivity, coffee quality, etc :)  Just let good engineers get to work.  If you're paying attention, you'll know is performing and who is committed to performance.