jessenoller.com

Steve Yegge hits a homer: Your requirements are stupid.

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

So does this exception come with a map, and some food?

I ran across this exception again today during some reading - and when I first hit it some time ago, I gave it the label of "best python error" (and put it in a bugzilla quip list).


TypeError: Error when calling the metaclass bases
metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases


Every time I read this error, my brain convulses and I suddenly find that it's 3 hours later and I'm not wearing pants.

Seriously: this error could be better done as:


TypeError: You're doomed!
1> Open the chest
2> back out of the room slowly
3> attack the ogre


Of course, I'm being sarcastic for those of you with a broken laugh-o-meter.

I just thought about something - what if you made error messages "realer" like:

IOError: you can not access that thingie right now, it's either not on disk, unavailable - or your stupid USB disk powered off again nubcakes



MemoryError: How in the hell did you do this in a language with GC? Stop it. STOP. OH GOD IT BUR (oomkill from kernel)


Looking for Test-Driven Python people (again)

Following up on my "Finding Python people is hard" I figured I'd send the call out again.

We're looking for local-to-massachusetts (we're in Acton, MA) people who are interested in joining a dynamic, quality-focused test/automation team. Ideally, candidates are fluent in both testing (areas may include: performance, regression, web, streaming video, storage) and Python programming.

If you're a strong testing person with some programming - maybe you're not fluent in python - we'd still be interested: We have no problem teaching you Python. If you're a strong Python person, but maybe without a testing background - you're also welcome. Internally, we use Java/C++ and Python - experience with all, or some of those languages is great.

Even if you're just starting out - perhaps you've just graduated college - we're looking for people that want to be great engineers. We look for strong engineer skills, contribution to open-source work - we're looking for people of many skill levels to join the team.

The role is for someone to join the Engineering team with a focus on Automated test engineering. We don't slot people into "just testing" or "just dev" - we hire great engineers, and people who want to be great engineers. The core developers help drive testing, and the testing-focused people help drive core development. The entire company is focused on providing the highest quality product to our customers.

As part of this role, you will be developing everything from simple unit tests to highly complex functional level tests. Some of the more challenging aspects include the fact that the product itself is very performance-driven, so the tests we develop (in Python) have to be able to drive a product capable of pushing tens of gigabits of video data across the wire to it's very limits. The product uses distributed technologies and is a loosely-coupled system - we have to test and prove that as well.

Internally, we're using such tools as the processing library for concurrency, Nose, YAML, etc. We encourage open-source contributions and community involvement (see the nose plugin I recently open sourced, and the PEP 371 work I've been able to do) and exploration of new technology that might help us devise more efficient testing strategies. If you like pushing boundaries - this is the place for you.

A great example of one of the challenges is a test I've worked on for some time - I've had to design a highly concurrent test that can leverage a single test client's resources to the max to drive load against the system, while also generating statistical anomaly events to trigger internal behavior to the system. Of course - just designing it for one test client won't scale: This test has to be locally concurrent as well as have the ability to spread out to multiple testing clients. Oh - and it has to generate hundreds of gigabytes of data as fast as it can to push the system.

Some of the technologies I've been personally exploring are the Actor-Model approach to concurrent programming, Twisted for asynchronous/concurrent testing, etc. No technology or approach is excluded - we approach all of the test development with the zen of python in mind:

There should be one-- and preferably only one --obvious way to do it.

And just to add to that: There is only one way to do it: The way that works. If we find that an old approach doesn't scale or do what we need it to do, and we have a new approach that can do it better, faster, cheaper, etc - we're not afraid to adopt it.

This is a startup: and we're really ramping up on the automation of the tests - so nothing is set in stone. We use Ubuntu, OS/X and even Windows for the development environments. Pick your editor, pick your machine - the team is focused on making us, and you successful. Every engineer in this organization is empowered to do what it takes to get the job done.

If what I am saying sounds interesting - send me an email, or post a comment. I'm very interested in talking to you.