An unbending tenant of eXtreme Programming is YAGNI, “you aren’t gonna need it.” As Ron Jeffries says:

YAGNI says, it never makes sense for a developer to implement things that aren’t asked for. It is always an explicit waste of the company’s money. It does not save money over doing the same thing later: the cost is the same, just spent later, which is a good thing. Making the marketing guys grin will not put money in the company’s pocket.

Much of Chapman’s In Search of Stupidity is an extended proof of why you’d want to use YAGNI to keep developers (and fame-crazed execs) from running wild with features. Any developer who’s suffered through hours long design meetings and protracted “debates” about how baroque to make a system become fast adherents to YAGNI as well. See KISS and Good Enough Software.

On the other hand, we have flickr. And del.icio.us.* And, oh yeah, Mr. $434.26, the GOOG.

“Some of the most intense users”

Cauvin linked to a set of interesting notes on Google’s product and project management taken in Jan. 2003 by Evelyn Rodriguez. On the topic at hand were these tidbits:

• Employees (called Googlers) are best source for ideas at Google — also some of
  the most intense users of Google with well-formed opinions.
• We get a lot of our ideas from our users (including customer support queue)
• Next iteration [of Google News]: Didn’t make it to user studies because Googlers hated it.

While these notes are from 2003, that was obviously a critical time for Mr. $434.26, so the software development approach they were taking at the time is obviously of interest.

And what’s interesting is how involved the “Googlers” (man, I’d kill myself if I had to go by that moniker) themselves are in playing the role of customer. In the world of Agile, that’d be a big poop-on-that no-no: in most Agile implementations, the product owner is the mouth-piece of the God of Features, The Customer.

At the other end of the spectrum are developers who are writing and using the software: those “intense users” at Google.

Eating Your Own Dog Food

In software, we call this “eating your own dog food.” While I obviously have infinite respect for everything else good product managers do, the eating your own dog food principle is the most important one to follow, and yet the one least used.

If you’re working on some big, complex piece of enterprise software, for example, ask yourself, “would I want to install this and configure it?” Chances are, the answer is no: in an enterprise software shop, one of the hardest things to do is to find a running copy of your software (dev instances don’t count). No one wants to go through the hassle of installing that beast, which usually involves several hours, cryptic error codes, and dedicating a whole machine.

The CEO Test

Never mind the ever insulting “my mother/aunt/some clueless old lady” test; a product manager I know has a real answer for this problem: “The CEO should be required to install every piece of software their company makes.” In other words, the CEO would have such a terrible time installing most pieces of software that they’d use their bully-pulpit to make install easy.

Install is just the first part of your software (and as the first impression a customer gets, ask yourself, “how much time do we spend assuring that the install makes the best impression?”). The next step, of course, would be to require the CEO to use the application weekly, if not daily, with the same hopefully result.

The flip-side is that as a buyer of software, one of your first questions should be, “tell me how your company uses this software. Give me details.” If a company — esp. a large company that has all the same IT concerns as any other company — doesn’t use it’s own software, they’re sales people better be ready to dance up a storm to explain why.

Agile Dog Food?

Charles and I have talked about the lack of dog food eating in Agile quite a lot in the podcast (esp. in the first two episodes: 1 and 2). We’ve never come to a good conclusion, except that there’s something missing.

As the Google notes above indicate, employees are often one of the best sources for features, esp. if they’re users of the system. There’s certainly some shuckin’ and jivin’ that can be done to say that Agile thinking addresses this (we listen to customers, programmers could be customers, ergo we listen to programmers). But, as of yet, figuring out how to harness the innovative abilities of the developers is something that most Agile software development methodologies as practiced don’t do well. Of course, you could knock out the word “Agile” from that sentence, and it’d be even more true.

* My gut tells me that flickr and del.icio.us “allow” their developers to drive features. A couple of quick searches didn’t find anything to confirm it, so for now my proof is simply my instincts. For Google, on the other hand, I have the above “proof.”