I watched an episode of My Name Is Earl the other day, and now I have the kickass song from Kill Bill running through my head. But I don’t know its name! So I go to google and type:

Kickass song from Kill Bill

Google’s answer (the one I’m looking for) is number four on the search list: Battle Without Honor or Humanity

Curious, I went to Yahoo and tried the exact same search. The equivalent answer is #7 on the list, although the name of the artist (HOTEI TOMOYASU) is referenced in #2.

Altavista - #1 is the same as #2 on the Yahoo list (the name of the artist), although #6 is the first one that mentions it by name.

MSN - #4, very similar to Google’s #4

Ask - #1 is the name of the artist, just like Yahoo and Altavista, but no mention of the song by name.

Bottom line - I was looking for a specific song from the album, and not the pseudo-title “Kill Bill Theme Song”, so I have to give the edge to Google and MSN. But a reasonable person might have been looking for “Kill Bill Theme Song” in which case Ask and Altavista both do better than the rest.

Seth asks ‘Why are you afraid of process?‘   Does it get in the way of intuition.

I dislike and yes, sometimes fear process because often they are used to avoid making hard decisions.   Or because they make it harder to do things differently.

There are all kinds of processes in this world.  I use processes every day to help me get things done faster and more effectively.   But I refuse to let those processes substitute for intelligent decision-making.  I’ve so often seen processes waste time and make the overall goals harder to reach, instead of easier.

For example, software architecture documentation.  There are document templates - that’s an example of a good process - it provides a framework for the vast majority of the common questions one might ask.  But then you try to fill it out, and in a broken process, there’s far more detail required in far too many sections that just don’t matter.   But according to the “process”, you can’t submit the documentation until every question has been answered.  Really?  Tell me, how does it matter whether this particular bit of software is ‘handicap-accessible’, when it is only going to be used inside an embedded device (imagine, if you will, the ‘next song’ algorithm on your iPod).

And yet there’s almost always some jerk who insists that you have to fill out the section explaining in detail why that particular part of the document doesn’t apply to you - because the process requires it.

There are good processes, and there are stupid processes.  At any point, changes to the world, changes to the business can cause a good process to become a stupid process, effectively perverting its original intent.
Those are the processes I fear.  The ones that make life harder, instead of easier.   And those are the ones that should be stamped out.

Continuing in our series of ‘We read marketing collateral so you don’t have to’, I present to you ‘Seven Keys to Building Great Software Projects’ by the Menlo Institute.

Here are the seven keys:

• Use a user-focused team to design your products
• Actively observe real users
• Conduct (user) interviews in phases
• Create highly specific personas
• Categorize scenarios as ‘daily’, ‘necessary’ and ‘edge case’
• Storyboard the user interface
• Perform cognitive walkthroughs

As you can see, Menlo Innovation’s primary theme is ‘user, user, user’, which makes sense given they way they describe what they do as High-tech Anthropology.

None of these are troublesome - I don’t put as much weight on personas, but we do try to do the rest.  The last one is probably needs more explanation - essentially you - as a developer/product manager/whatever will be well served by trying to “think like the customer” and view the product as if you were the customer using it.   Does the design work for that customer?  If not, you have more work to do.

The author feels that #1 is the most of the keys - the one that carries the rest.   And in general, I agree - without a team that thinks a happy, productive user is job #1 will usually be able to come up with a good result, whether they follow the other practices or not.
Overall - it’s fairly dry, but if you have questions or want more information, visit the Menlo Innovations website and check it out.  I’m not exactly sure where it is on their website, I think you have to sign up as an email subscriber, but they haven’t spammed me yet.

Rating:  B+

The latest version is up - by our newest contributor - Kevin Rutherford. Great job, Kevin!

In doing your project, don’t wait for others; go after them and make sure it gets done.

Perseverance and followthrough are extremely important habits for an effective leader. Of course, so is knowing when to quit, but is a much harder lesson to learn well.

But the important points about this particular rule is that you can’t just built the habit of delivery in yourself. You have to make sure other people are delivering as well. If they don’t (and they’ll have a thousand reasons why), don’t be caught by surprise. Be aware, and to the best of your ability, find ways to either move the work onto someone else, or get them to up the priority of your work.

For me, this is where creativity gets to play. How can we find creative ways to address the bottlenecks and challenges?

This reminded me powerfully of the XP concept of turning up all the dials.

Reasonable economic cases can be made for allowing people to sell their organs, and for allowing people to buy the ability to immigrate into our country.  Cautious people avoid such proposals, because they push too many emotional buttons.  Mischievous folks like myself, however, wonder what happens if we push all the buttons at once: what if people could enter the country if they give up a kidney, or similarly valuable organ?  Would those who worry about the loyalty of immigrants who just pay cash to come here be reassured by the symbolic loyalty of giving up an organ?  Would those who fear that organ sellers are exploited be reassured by the huge value immigrants gain from living here?  Impish minds want to know.

Regardless of where you fall politically on these debates, I hope you appreciate the paradigm-shattering creativity of combining the two concepts together.   The next time you have two different, difficult problems staring at you, perhaps you can consider interesting ways to play one off of the other.

Someone stole my idea to build an app combining the eye-candy of Flex with the web-dev coolness of Rails.

Actually, I’m happy someone else did this, since I don’t have the spare time to work on this with all my other projects.

The tutorial is very well written. I will enjoy looking at it with more leisure when I get a chance.

*Update* - changed the URL to point to the new location of the project.

It’s been a while since I’ve gotten to this. My apologies.

Don’t be known as a good starter but a poor finisher!

This is definitely one of my weak spots, as demonstrated by how long of a time lag I left between #8 and #9 on this list!

The “Getting Things Done” philosophy has helped me here in the past. Guess what else I’ve let lapse for the last couple of months? Really, I have no one to blame but myself

My boss refers to himself as a ‘closure fanatic’. I’m not sure I’m totally on board with that, but he is definitely more interested in getting things wrapped up than many others. The desire to get things wrapped up and put away is a major, major value point for most successful… anything. The old Pink Floyd lyric comes to mind - “plans that either come to naught, or half a page of scribbled lines.”

Even if what you are disappointed in what you’ve produced, finishing it and putting it behind you is far more valuable than letting it drift away. You learn a lot from closure, you may even find new opportunities to improve something or new ways to use it.

From the title, I thought that this was going to be a tutorial on using a symbolic debugger (which I have grown to despise in a web-based world).  But instead, it is an overview of many of the ways one can find defective code, including lots of “social” techniques for finding the problems without even (necessarily) looking at the code.

I’m pretty sure I’ve used everything on his list at one point or another.

I would also say that recently I have found the more unit tests I write, the less I have to use these techniques…

This is a well-written tutorial on some of the exotic functional programming aspects of Ruby.  I learned a couple of things.

Unfortunately, I have a procedural-programming mindset.  Blocks and Closures, like my sword collection, are, for me, interesting but of little practical value.  It’s on my todo list!

Oh, and here’s a tutorial on symbols in Ruby  (the :yourname construct).   I must say I was disappointed with the ending - I thought there would be more pizazz.

A significant plurality of Cilantro haters agree that Cilantro tastes like soap.

Just knowing that this forum exists makes me feel better about my intense dislike of Cilantro-infused foodstuffs.

A commenter pointed me to this article on the struggles and frustrations of an enterprise architect.   I have no particular quibbles with the author or the post - he seems to be trying to figure out how to deal with a difficult environment.  But I do think that over time, he has given up the good fight, and let “that’s the way we’ve always done it” rule his thinking.

Now, admittedly, I don’t know anything about Enterprise Architecture, since over the last nine years I’ve been the only architect, one of two or (luxury) one of three architects for the entire company.  I’ve only had to integrate products and services with F500 architectures, I’ve never had to own one.  Correspondingly this “fisking” of the previous artitle resonated with me.  But after further reflection, I think it is also unfair to Mr. McIlree is working for a large company.  People who work for large companies typically do not care about the company.  They care about having and keeping a job.  For many people, their employer is nothing more than an endless salad bar - whose function in life is to provide the employee with a salary.  (That, typically, is one of the key differences between working for large and small companies)
In that kind of environment, large budgets are a symptom of sponsors who care about their own projects.  Let’s say we have Edna, who has money for a project that will improve her department.  Because of architectural constraints, it will cost her $1MM (1 million dollars).  Now, you’re the architect, and you know that with a $2MM extra investment, you could do a radical overhaul of the company’s architecture and make it so the next project for Edna would only cost $100,000 instead of $1MM.
But Edna is not going to authorize $3MM to pay for a $1MM project, unless she’s astonishingly perceptive or swimming in excess budget.  It’s not particularly fair to her to expect her to do so.   So you have to try to go to all of the department heads to convince them that $2MM divided up by 10 departments is a pittance in exchange for a cheaper/better/faster enterprise.

But I doubt that it would work.  Why?  Because many of those department heads know that they can free ride.  If you can get the other 9 to pony up $220K, they get the benefit for free.  And suddenly, only a couple of the department heads are in, and they aren’t willing to shoulder the cost for everyone else.

And so the architecture stays expensive, stays cumbersome and unresponsive, and the architect continues to be frustrated trying to make a difference.  In thinking about how I would solve this problem, should I ever be so fortunate to be in a position where I can, I would create a policy where IT projects automatically have a 20% ‘architectural maintenance’ tax attached to them, specifically in order to pay for ongoing enterprise architecture improvements.  Not sure if it will work, but it’s the best idea I’ve had on the subject so far.

I was the speaker at the April 11th meeting, but instead of lecturing, I thought it would be more interesting to have a roundtable discussion on the following topics:

• Are backlogs waste?
• Who owns Scrum?
• What are good metrics for agile projects

We had a pretty good turnout, and some interesting ideas for future meetings - specifically a discussion of how people vary the practices of the agile methodologies for their own organization.

Are Backlogs Waste?

This was brought up on the Scrum development Yahoo group.  The general consensus locally was “no, of course not”, so I felt obliged to take the contrary position to get some discussion going.  Lots of good pro-backlog points were made:

• If you have more ideas than you can handle, you need to write them down
• Backlogs represent a “warm blanket” for the customer
• Backlogs are a critical buffer/shield for development, to keep them from getting interrupted (You want that feature?  We’ll put it in the backlog)
• Some think the name is bad - instead of calling it a “backlog”, call it “Planned Features” (Jira does this, apparently)

Some anti-backlog points:

• If the backlog grows beyond some point, it becomes ridiculous, and undermines morale
• Customers may become cynical or jaded if their needs are buried in the middle of a huge backlog
• Providing estimates and tracking complexity on a large backlog is waste if those items will never realistically be worked on
• A large backlog can be intimidating to the team and to the customer.  If it’s intimidating, it probably isn’t agile

The lukewarm consensus was that a backlog needs to be segmented informally into “likely to be worked on” stuff and “unlikely to be worked on” stuff, to help mitigate the waste.

Who owns Scrum?

I specificaly used Scrum for the discussion, but the problem could just as easily be applied to XP.  The main point of debate was “Should Scrum (or XP) be controlled by a single person or a small group, or should it be left alone to be freely interpreted”.

• Someone suggested that Scrum and XP be turned over to ISO for formal standardization, to a bunch of laughs.
• Some feel that RUP’s strong ownership actually stifled it, and kept it from being applied more broadly
• Someone pointed out that by tweaking the process individually, we are demonstrating that it isn’t really owned
• This caused a further discussion on whether ownership meant “no changes allowed” or more broadly, “no one else can call what they do Scrum”
• Someone raised formal certification - like ScrumMaster certification - is it a good thing?  I personally think it is - it gives more “heft” to the opinions of people who are certified, versus people who “read a book” on XP and then declare themselves experts (as an example).  Formal certification can’t really happen without ownership.

The best Agile Metrics?

We discussed the attributes of good metrics - they are hard to manipulate, they are timely, they are correlated to the task at hand and they are consistent over time.

1. Running, Tested Features
• This is Ron Jeffries’ concept, and it is fairly hard to manipulate (assuming the person who decides which features are in an iteration is independent), but it isn’t very timely.  It is very well correlated to the task at hand, but it is only moderate on consistency over time
2. Story points
• Easily manipulable, but very timely and well correlated.  It does suffer from conceptual drift - what was complex a year ago may be easy now
3. Sales
• Wonderfully hard to manipulate, very consistent over time, but neither timely nor easy to correlate with the task on hand.
4. Function Points
• Fairly easy to manipulate, difficult to maintain consistency - new technology will change the complexity of a given solution.  Fairly well correlated to the task at hand.  One person felt that feature points over the course of a Release (multiple iterations) was valuable, but over the course of a single iteration was not.

Some good points were made vis-a-vis what metrics are for:

• To measure how your team is performing vs. other teams
• To measure how your team is performing vs. its own history
• To measure the impact of changes to the environment - for example, if we turn the heat up to 78 degrees, does that make things better or worse?  If we give everyone offices, does it make things better or worse.  Until we can answer these questions, intangible metrics will always lose out to tangible ones (like the cost of the office or the money saved by raising the thermostat)

Other metric concepts that were thrown out:

• Features into QA and out of QA (identify bottlenecks)
• Number of times a bug goes through the “opened, solved, reopened” cycle
• Incomplete features at the end of a sprint
• Requirements churn
• Number of tests for the Iteration

My own suspicion is that there is no one true metric.  We need several metrics, rigorously measured over time to get a sense of the scope of the problem.  That’s not a very satisfactory answer, but it’s the best I have right now.

Wrap up

The group seemed to really enjoy this format, suggested we do more of these in the future.  I used a 20 minute timer to manage scope for the three parts of the discussion, which seemed to help quite a bit.  It was suggested that we bring up topics for future roundtable discussions on the mailing list, and that we should create a “backlog” of roundtable topics when speakers weren’t readily available.

Cedric writes a thoughtful critique of Ruby on Rails.

Many of his points are quite valid, and I have no doubt that Rails can falter and end up in Smalltalk zombie mode, doomed to shuffle the earth uselessly for the next 100 years.

But I think that most of the larger-enterprise bloggers and commentors are making a specific, paradigm-limited mistake: Because our IT organization would not voluntarily support this, it cannot succeed.

But that particular viewpoint is flawed, because IT departments are forced to involuntarily support new systems/services/capabilities all the time.

Consider Microsoft - they bought Hotmail, who used, if I recall correctly, BSD Unix for their servers.  What if Flickr had been written in Rails, and been just as successful.  Would the people at Yahoo who made the decision cared much about what language Flickr was written in? or Del.icio.us? Probably not.

Here’s what I believe: I believe that web development with Rails is faster and easier, even though I have not found a good IDE for it yet.  (I haven’t tried that many, thought).  I believe that a small group, even as small as one person, can write an app (like this one) in Ruby on Rails, and have it successfully develop a user base, without requiring significant VC investment.
Given that premise, that people can develop effective applications in Rails with minimal expense, is it unreasonable to assume that many such entities will be created?  There are already Rails hosting providers (TextDrive and Rails Playground, for example).  Hosting on Rails Playground is exceptionally cheap, even by my frugal standards. ($2/month). Setting up Rails applications on this platform is trivial, nearly push-button.
If we assume that yes, people are going to develop useful and effective web applications in Rails, what happens next?  Larger companies buy them.  Maybe not BaseCamp, and maybe not any of the application we are familiar with now, but there are all sorts of ways that Rails applications could end up “involuntarily” supported by F500 IT departments.  And no, I don’t mean John Deere.   But Google, Microsoft, Yahoo, AOL, Disney, Amazon, IBM? - all candidates for finding interesting webapps that appeal to them and bringing them in house to extend their depth-of-service.

And at that point, the question switches from “How could it possibly be integrated” to “Ok, how did those guys do it, and why can’t we?”

And then, like Linux, Tomcat, JBoss, MySQL, PHP, Bugzilla and Firefox before it, Rails will de facto become an acceptable part of IT infrastructure.

Guaranteed? By no means.  And it won’t happen overnight.  But the rise of Rails is by no means impossible either.  I’m not even sure I would call it unlikely.  I’d say it’s probably 50/50 we’ll see at least one or two F500 companies with Rails-based applications in play in the next 3 years.

Pete Behrens hosts the current iteration of the carnival.

We’ve moved to a twice-monthly format for the moment, so the next one will be April 20th.

Priceless.

The article is a little haphazard in the middle, but it’s full of great points and insights about the tensions between IT and the userbase.

Neat technological study - for $100 and a blood draw, you can have your DNA analyzed to determine where your ancestors came from.  Very cool!

If you’re like me, you were fascinated by building toys as a kid.  Heck, I’m still fascinated by them, and I get in there and build all sorts of fun ships and buildings with my kids.

So the claim that software is in the Lego era is pretty interesting.

Digging into the article, it’s generally focused on web services - mashups and other exotic particles that show how one can take information from google maps, combine it with information from Craigslist and get a geographic model of where apartments for rent can be found.  Or how a business has been created using Amazon’s mechanical turk, able to charge pennies for services that used to cost dollars.

After thinking about it, I’m not sure that it’s so much that the software is lego-like, but rather the valuable services that companies offer are becoming lego-like - able to build on top of each other and create new and interesting ways to solve problems.

Because at the end of the day, building a large-scale web application, supporting fee collection, subscription management, integration with third-party servers, network management, customer service, fancy modern javascirpt (ajax) and all the other accoutrements of modern apps is still a big, custom job.

Granted, there’s probably a business there - providing a “large scale web application framework” for companies to build on.  Perhaps Yahoo already offers it via the Yahoo store.   I don’t know, I haven’t looked.

But I still think we have a ways to go before software itself becomes lego-like.  Alas.

One of our “must do” projects is getting strangled for resources by all of the other “must do” projects.  My boss threw out the suggestion that we focus on delivering something - anything visually meaningful, instead of worrying about the infrastructure.

Given that the alternative is to abnormally terminate, (and as my previous rants have indicates, its doubtful that terminating the Sprint would in any way make things better), this seems like a reasonable strategy.

The other difference - instead of a 3 week Sprint (the PM’s idea, not mine), we’ll try to deliver some visual functionality each week.