Steve Yegge hits a homer: Your requirements are stupid.

by jesse in , ,


Lately, I've been ruminating on requirements and requirements management (also known as disaster control). I was actually typing something up on this, but Steve Yegge hit the nail on the head - then he rammed it through the board and into the house next door:

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


The Abstract Cheetos Attack.

by jesse in ,


I need to write a CERT paper for this -

  • 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"


Pep Turds

by jesse in ,


I've finally been given the "gift of time" to work on the processing module PEP - when I was reviewing the text template, I ran across this:

- 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.