In another media company which tried to jump the music download bandwagon, a service they killed soon after Apple started dropping DRM I was in a project where a couple of stakeholders had various meetings about how the search pages and “microformats” for music download items should be designed. A couple of approaches from various business guys and managers a “simple” DBA or sysadmin stood up and said “This is all Bullshit, let’s try the opposite approach”. And it worked just fine for us to design and implement it in a few week’s time.

I know a few similar episodes, but this probably meets your tagline best..

I heard recently about a team that had a story, something like “Migrate to new database.” This never got prioritized in a work sprint. The business and developers just kept pushing it back putting other stories in front of it. Then, finally someone rewrote the story better: “As a developer I want to migrate the database from Oracle to Postgres so that the business can save hundreds of thousands of dollars per year.” Well, guess what, that revised story took precedence over all others ;)

It’s also true about having one single visionary. There’s another interesting methodology called DSDM (http://en.wikipedia.org/wiki/DSDM). They actually define a role in software development called the “Visionary,” a person who is responsible for the direction of the product. This always reminds of the Mac OS X desktop. I read somewhere that there is *one* single person who approves UI decisions. I personally think OS X has a great user interface and if this is true then it certainly proves the importance of making one person (not a committee) in charge of the really hard decisions.

I don’t think anything either one of us has said runs counter to the idea of mission-critical applications. Especially when designing those types of devices and applications it’s important not to muddy the waters with useless features, ideas, or requirements. It’s critical to “keep to the core” — do one thing, and do it exceedingly well. Design one thing: And design it well.

Do not create things you yourself — or your company — you would not use. Requirements are good — they define what you have to do, but where those requirements and features come from is the key to what we’re both saying.

As for waterfall going the way of the dinosaur — well, you obviously haven’t worked in a lot of bigger software teams or groups, or with people who “came to age” in that era. The waterfall method of requirements definition is very alive and well, much to the chagrin of many :)

The same applies to specs — you can design a per-the-spec NFS server, but guess what? Most clients on the desktop and server are *not* spec compliant. You will always be making concessions to clients that played it fast and loose.

It’s much better to identify your core users (of which you are one) and write the software to help and serve *them* — not the spec.

Ultimately I think Steve’s post stands on it’s own: Build something you love, use and believe in. Don’t build something for some mythical audience with a made up set of requirements which will ultimately not serve them properly — a product that only does 50% of what they need, 50% of the way they need and want to work will ultimately fail.