� Phil on “Functional specs subvert the hierarchy of nature”
Philip Greenspun’s process recommends simple, obvious interface early on. Joel’s functional spec is a document of screens when you boil it down. Actual HTML interfaces is just one step further than that. I realized that Getting Real isn’t as radical as I had first concluded.

� Brad on “Functional specs subvert the hierarchy of nature”
Only spend your time on activities that bring you closer to your actual goal. Everything else is just noise…If your goal is a nice, well formatted library of documents that everyone in your company has contributed to and agreed on, well then, get on that functional spec or 2 year projection. But if your goal is an actual product, cut out the things that chew your time and don’t contribute to actually building what you want to build. If you need buy in, make a phone call to the person who makes the decision instead of calling a meeting. Avoid the silly business busyness procrastination that amounts to wasted effort and lost time.

� Martin on “Functional specs subvert the hierarchy of nature”
A two-page project scope document that lists objectives, expected outcomes, assumptions, and resources required is probably all you need for 99% of the work out there, and will likely provide as much common information as people will be comfortable processing.

� Shawn Smith on “Functional specs subvert the hierarchy of nature”
Still, there are a few things in my experience that determine just how much spec documentation a project needs:

1. Complexity - If it takes more than one brain to contain the thing, then you need to transmit and receive (transmit what’s in your brain and receive what’s in other people’s brains). Complexity creates dependencies (you need to know x in order to do y). Complexity often means there are a lot of ‘if’ statements and alternate or conditional scenarios.


2. Bulletproofness - If a mistake will result in loss of life, liberty or a lot of money, then risks need to be eliminated (not just mitigated) and butts need to be covered. For one thing, this means it’s complex (see previous point). If you’re designing an aircraft or a nuclear plant, then documentation helps you make sure you build and test every nook and cranny of the thing.


3. Team Distribution - The more distributed your team is across space and time, the more dilligent and thorough you need to be about documenting things. If you’re designing something that’s going to be built six months from now by some unknown team of people halfway around the world, then your design had better be thorough. Your documentation could reside in the code itself, but it needs to exist. Of course, it’s in the best interest of everyone to minimize the space and time between team members.


4. The Client - People don’t like to spend money without knowing what they’re getting for it. It’s cheaper to revise (or scrap) a product that’s still on paper than after it’s built. Of course, rough prototypes can sometimes replace paper artifacts, but not always. If the client stakeholders you’re working with don’t have the authority to approve the work, then you need to provide them with things to show and tell internally. Sometimes this means paper.

� Geoffrey Graham on “Functional specs subvert the hierarchy of nature”
There are striking similarities between the concepts discussed here (the development of web-based environments) and the ongoing discussions of the development of our built (i.e. land, houses, etc) environment. So much so that I am stuck everyday with an Ah-ha! moment that shines a glaring spotlight somewhere. This is one…I encourage you to check out Jane Jacobs’ “Death and Life of Great American Cities” to get her prescient (1950s) comparison of evolved (vibrant) communities with authoritarianly planned (dying) communities. More recently (late 90s), she applied the same kind of analysis to all types of organisms (whether small groups, living eco-systems or economies) in “The Nature of Economies”…Her finding: Rigid Plan = Crap; Responsive Design = Awesome.

� well on Innovation is not proportional to money spent
innovation often comes from rediscovering or slightly modifying ideas from 20-30 years ago that were either poorly executed, impossible to realize at the time, or too far ahead of their time for industry blockheads to appreciate…that’s why python, ruby, and other dynamic languages that consist of a C-style language with piecemeal components of Lisp/Smalltalk are so “innovative”.

� erwin blom on “Fly on the wall: ‘pony integration is a deal breaker’”
I recently interviewed Martin Stiksel of Last.fm. Click on his image and watch and listen. Personally, i think Last.fm is one of the best new music services. This is what he has to tell (don’t be afraid, the interview is in English, not in Dutch!): http://homepage.mac.com/erwblo/checklist/page3/page3.html

� Sam Stephenson on “Fly on the wall: ‘pony integration is a deal breaker’”
Tables can be evil, but not because semantics weenies say so. Table elements are notorious for exhibiting wildly different behavior in each browser when manipulated by the DOM/JavaScript. So from a practical standpoint, I’ve found the path of least resistance (at least when you’re scripting the page) often means avoiding tables whenever possible.

� J Aaron Farr on “Fly on the wall: ‘pony integration is a deal breaker’”
Having worked in a number of large corporations I’ve found it a shame (and frustrating) that I’ve been unable to use some of the best tools available because of silly policies. Businesses want to insulate themselves from risk but do so by exchanging innovation and trust for mediocrity and regulation. They throw up walls and filters in order to only allow the safe players to get in. Meanwhile, the best players can just avoid the hassle altogether.