The Filter 37signals 17 Mar 2006

6 comments Latest by Sali

Some interesting comments posted this week at Signal vs. Noise:

JF on “The Cost of Bootstrapping Your App: The Figures Behind DropSend (part two)”
If the app starts going, but you don’t have the revenues to expand, then something else isn’t right. Growth in your user base should equate to growth in your revenue base. If it’s not you need to rethink your model.

Bastiaan Terhorst on “Screens around town: Firefox vs. Safari tabs, NFL, NY Magazine, Isaac Wardell, and a Backpack portfolio”
I actually prefer safari-style tabs…Google studies agree:

Robb on “Screens around town: Firefox vs. Safari tabs, NFL, NY Magazine, Isaac Wardell, and a Backpack portfolio”
The New York Magazine “print links” options is quite nice. I first saw this sort of thing at A List Apart as a clever script and CSS2 combo that would automatically include the links as endnotes when printing.

scott on “Sunspots”
153 has many curious properties.

Alex Bunardzic on “Functional specs subvert the hierarchy of nature”
If I’m not mistaken, 37signals acts from a ‘software nutritionist’ position (I wrote an article about that:…It is naive to assume that people despise inefficiency and can’t wait to shed the rigid bureaucratic shackles. One of the main reasons people like to aggregate and organize large workgroups is just so that they can exercise all these code laws. They don’t really care about the common laws, the organic fluidity and all that…The spontaneous flow is more reserved for the individuals, for the artists, the creators among us.

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 Click on his image and watch and listen. Personally, i think 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!):

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.

6 comments so far (Jump to latest)

Aaron B 17 Mar 06

Meta Commenting!

Tumble 17 Mar 06

it’s a clip show!

Tony 17 Mar 06

Too bad you couldn’t have gotten Troy McClure to host.

Dan Boland 17 Mar 06

Have no fear, we’ve got stories for years! =)

Matt Todd 19 Mar 06

This particularly impresses me: it shows me that you guys are reading on here what I’m reading on here (and, as you know, that’s what matters to me).

Good job on keeping up with your community.


Sali 28 Aug 06