Anyway, there you have it: the slightly expanded version of the email I sent that CEO guy. Gathering business requirements is hokum. Hooey. Horseshit. Call it what you want, but it’s a sign of organizational (or individual) cluelessness. If you don’t already know exactly what to build, then you’re in the wrong business. At the very least, you should hire someone who does know. Don’t gather business requirements: hire domain experts.

Also, FWIW, here’s the hackernews discussion. Here is a link from one of the comments pointing to something Linus once said about specs:

they’re dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.

I think one of the comments also added something spectacular — noting that “building something for yourself” is why so many open source projects flourish. If you’re building something useful for yourself — there’s a high chance that someone else is going to want to A>Use it B>Buy it — “building for yourself” is also in some ways, “keeping the vision clear”

One of the key concepts which seems to be the undercurrent to what he talk about is vision. You need someone who can stand up and say “this is what the product is, does and where it is going”. You need that visionary who can clearly outline what itch you are trying to scratch. In open source — that’s the project “core” — in business, it’s the CTO or founder. It’s always the person that had the itch, they’ve “walked a mile in the shoes” so to speak.

That vision has to be the core of both the product, and all of the requirements — this “clarity of vision” (some might say “simplicity of vision”) is what makes so many projects and products successful.

Sure — as you grow you’ll add features: You don’t want to stagnate — but those features have to make sense — they have to mesh with the core vision of the product. You don’t add a source code management service to say, twitter.

Why? Because even if 1 customer thinks “that it would be AWESOME” — you’re going to spend $X hours of engineering time gluing a volvo on the side of your battleship, and unless those $X hours are compensated by the amount of money the customer is willing to pay (it never is) you’ve wasted time, and muddied the functionality and philosophy of the product. It’s about as useful as a screen-door on a submarine.

When you’re thinking about requirements ask yourself this: If at the start, you can not describe exactly what your product does in under a minute — you’ve already got a problem. If adding this feature makes it even harder to describe/encapsulate the vision and capabilities of the product you’re rapidly running towards wronger-than-wrong.

If you yourself would not use the feature: Does it really make sense? When a customer requests a feature — does it make sense for anyone outside of them? Would you be better served by providing an API and an SDK?

This is the beauty of things like a clean API — you can keep the philosophy and core of the product/project clean and empower your users to build any number of things they want on top of your product. Keep it simple, keep it clean. Empower your users to “mashup” as they need or want to.

Think of it terms of cooking: If you wouldn’t eat it yourself, in all likelihood your customers won’t like it, at best it will be mediocre. The best chefs taste and consume what they cook.

Right now I’m wishing Brian Fitzpatrick’s keynote from pycon: “You *can* Fool All of the People All of the Time” was online in video form.

See also: THE TECHNOLOGY OBSESSION by S. Lott

• Name of Attack:The Abstract Cheetos Attack
• Type of Attack: Password Vulnerability / Local Exploit / Brute Force
• Known fix: Lack of Cheetos
• Attack Vector: Food[1]/Social Engineering
• Exploit Details: It is possible to determine the most-frequently used letters on a given keyboard on the target’s computer by providing the target with a “friendly” package of Cheetos at some regular interval, and then examining, over time, the build up of dangerously cheesey residue on the target’s keyboard. Armed with the most frequent keystrokes, it is possible to perform a reduced brute-force attack on the target’s account password. Due to the reduction in keys, it is possible to grossly reduce the time and resources required to identify the target’s password. This attack also enables the attacker to determine other personal information including frequency of hand-washing, like/dislike of said “Food” and frequency at which the target cleans their clothes.

[1] Note that Cheetos may not be classified as “Food”

These are the ideas I get when I’m coding and thinking about food.

— Leave the little Emacs turd at the end of this file alone,
including the formfeed character (“^L”, or \f).

I should really switch to a turd-friendly editor. I think VIM or Textmate are scatologically disinclined.

Disclaimer: The opinions expressed here are my personal opinions, views, discussions, etc. Content published here is not read or approved in advance by HDS, my wife or anyone else for that matter and does not — in any way — reflect the views and opinions, positions/etc of my employer. This is my personal, largely python-related blog. Not my employers.

That being said: A few months ago, I discovered (much by accident) that HDS (Hitachi Data Systems) has started a viral marketing compaign involving Mr. T — yes, the man from the A-Team (whose face graced my lunchbox as a child). Note that massive “lulz” were attained when watching these.

Without passing judgement or in any way stating a direct opinion, here are the videos, in order of creation:

• Mr. T: The “T” in I.T.
• Mr. T: “T The Trucker“
• T3: MR. T — BATTLE FOR THE SMB

For additional amusement, I will direct you to the Archivas (before we were bought by HDS) viral/spoof/etc video that made it to youtube, here.

My question: Can they do a followup, “how not to be the embittered cynical old coot” or “How not to eyeball new technology with dismay, distrust and a long stories about how “you used to have declare variables in the constructor back in the days and you loved it””?

(Via digg.)

Presenter (Microsoft Employee): “What’s you’re favorite color?“
People: “Blue Blue Purple Blue… etc“
Presenter: I’ll use green
Person in back (paraphrased): “Typical Microsoft response to Customer requirements!”

Another Quote
Presenter (Microsoft employee): The reason we called this CLR is because we… Oh, I’m being taped aren’t I? Uh, we used a certain search* engine and found all references of Python + CLR pointed to IronPython.

* GOOGLE.

I am really excited about the intel laptop (macbook pro) — I’m underwhelmed by the name, but I am excited about the specs, and most of all, that if I can get my paws on one of them, I’ll be able to probably compile a lot more Unix/BSD/Linux applications, and I think that long term, we’ll see a rise in virtual machine support (and Wine support) for the platform.

As a Developer/QA person, I’m really quite happy with the transition. This might make getting more OS/X Python bindings and libraries into the core Python dist easier, and actually open quite a few doors.

Well, that and it has awesome specs, and will play World of Warcraft 100x better than my current box.

Meanwhile, I saw this switch video on gizmodo. I spit coffee.

Lord Jobs… RISE!