Mar 29

I just finished the 37signals book “Getting Real” yesterday and wanted to share some thoughts. We bought a 10-user license the day it launched to give each one of the members of the G7 pilot program. Having followed the 37s blog for well over a year, I like their philosophy and we knew this would be a good distillation of their principles and a good way of indoctrinating this philosophy in our own peeps. First if you are in the web application development industry and do not know who 37signals is, you are some kind of ostrich – these guys are the success story of a small business. They were a tiny usability-focused design firm a few years ago that stuck to their guns, kept lean and focused on simplicity. They now arguably have the most influence of any sub-10-person company in web development. They “scratched their own itch” by productizing Basecamp, a tool they had created for internal use of managing the development of their own projects and have turned it into a massively-popular solution for collaborating on projects. They have a no bullsh*t approach to everything they do that is so refreshing and have near-religious following on their blog Signal vs. Noise in terms of the loyalty of their readers. They have created a few other products like Backpack, Tada List and Campfire all of which are interesting for their interface design but none as popular as Basecamp (we’re using Basecamp in G7 in conjunction w/ Trac & Subversion to manage our projects). So enough of the ego stroking, overall impression of the book:

Get it. It’s cheap ($20) and it’s available instantly in pdf. It’s a quick read and while you may find no single piece of mind-blowing info that revolutionizes the way you do things, it’s a great way to assess and tune your own philosophy towards software development. They have a minimalistic style and are very much consistent with the AGILE philosophy of rapid iterations and getting a barebones working application developed quickly and in the hands of real people so you can get empirical feedback to guide the development of the product. The book covers the full cycle of research, development, testing and deployment and addresses aspects of application development and design. About 20% of the entire text is peppered with words of wisdom from heavy hitters like Joel Spolsky (Fog Creek), Seth Godin (Purple Cow) and Derek Sivers (CD Baby). It’s a quick read (maybe half a day if you do nothing else). The particular points I found interesting:

On having an enemy – this may sound counter-intuitive – we should avoid having enemies right? But when you’re developing a product, it’s helpful to identify the ones in your space that you hate – it helps you crystallize the essence of what your product will NOT be, how you differentiate it from the existing options and helps galvanize your staff with a mission. You obviously can’t focus exclusively on trying to beat competition, but having an “enemy” to reference makes the game more fun. Their thoughts on “tell a different story” are very much in line with the ideas espoused in the Innovator’s Solution on not picking a fight you can’t win. If your competitors tout feature robustness, go after simplicity. If they flaunt their impeccable support for every browser since Netscape 1.0 – go after responsiveness, a snappy clean interface and only support firefox and safari…

On emergence – Their thoughts on API’s facilitating emergent behavior echo our own at Grid7 – the more you can expose the functionality of your applications outside of the visual interfaces which you conceive, the more you open up the door for others to remix your app, build on top of it and take it a direction you hadn’t imagined when making it. Even though it’s not listed on our G7 homepage, we’re spending the majority of our time right now developing an extremely forward-thinking approach towards how data like job postings, book reviews, events and anything structured will be shared in the future. It involves structured blogging and microcontent and it’s the brainchild of my partner Kimbro Staken. You can read more about this whole initiative from the “tag” page of Grid7 here.

On where the real gains are – This an extremely insightful paragraph from p. 50 and it’s something I’ve known but haven’t seen it expressed anywhere as eloquently:

The best designers and the best programmers aren’t the ones
with the best skills, or the nimblest fingers, or the ones who can
rock and roll with Photoshop or their environment of choice,
they are the ones that can determine what just doesn’t matter.
That’s where the real gains are made.

This is so true- think about all the time you spend learning new facets of a language or the latest ajax widget to make a form work 1% better than how it does now. All this effort to add more flare would be better spent pruning what’s already there and delivering a more stripped-down, intuitive version that lets the user achieve their goal more simply.

On team size and distributed decision-making – this is another great paragraph and is literally at the heart of Grid7 (the 7 originally meant no team above seven people):

As projects grow, adding people has a diminishing return. One of the most
interesting reasons is the increased number of communications channels. Two
people can only talk to each other; there’s only a single comm path. Three
workers have three communications paths; 4 have 6. In fact, the growth of links
is exponential…Pretty soon memos and meetings eat up the entire work day.
The solution is clear: break teams into smaller, autonomous and independent units to reduce these communications links.

On the value of enthusiasm over skill – I can’t stress this enough – I would way rather have someone who is stoked about learning and has an idea they’re passionate about vs. having an elitist recluse who may be the best programmer in the world but has a condescending attitude towards the others on the team. What you know at any given time in our industry is not nearly as important as your ability to adapt, how well you can learn to learn and your passion for what it is you do. I said it in my talk for Refresh the other day, “of the six questions involved in any project- the what / where / when / how / why / who, if you can get one and only one right- fix the WHY solidly in your gut and the others will find a way to resolve themselves.”

On creating prototypes before code – Amen. Before you write a line of application code you should have already sketched out the screens from the app and the flow of the site so you know how it will work. Next step is to translate these into a clickable prototype so the people using it can see what’s involved and provide feedback that will invariably alter the design of the application and hence the code that you would have already written. I did this when first starting the ABC extranet project and it proved to be wildly helpful. I mocked up a wireframe initially using paper and then converted it to a digital version using Adalon, from that I was able to generate this HTML wireframe which I went over with the client and refined until we had all the screens accounted for. Next I threw together a clickable HTML prototype of that wireframe (no logic, hardcoded, CSS from another site since it would be changed eventually anyways) so the client could see exactly how it would work. This is apparently the exact process 37s uses which is encouraging and validates how we are approaching development.

Interesting byproducts of this tactic they pointed out that I had never considered were the improved vision/enthusiasm of the developer, the ability to make better estimates on time/cost and the compass function it served in guiding the development effort. Read this paragraph:

Once the html mockups were completed, we approached our developer,
Scott, with the idea for Blinksale. Having most of the ui designed up front
was extremely beneficial on several levels. First, it gave Scott a real vision and
excitement for where we were going. It was much more than just an idea,
it was real. Second, it helped us accurately gauge how much of Scott?s effort
and time it would require to turn the design into a functioning application.
When you?re financially bootstrapping a project, the earlier you can predict
budget requirements, the better. The ui design became our benchmark for
the initial project scope. Finally, the ui design served as a guide to remind us
what the application was about as we progressed further into development.
As we were tempted to add new features, we couldn?t simply say,Sure, let?s
add that!? We had to go back to the design and ask ourselves where that
new feature would go, and if it didn?t have a place, it wouldn?t get added.

On the choice of languages and how it affects the developers you attract – I’m well aware of all the productivity-enhancing elements of RoR for doing web apps but something I had not considered was the point they made about how the choice of language/platform in creating an application to some extent determines the mentality of the people that will be working on the app. Think of the various choices out there (php, asp, cf, jsp, asp.net, ruby, python, perl) – now think of the stereotypical developer for each language and how you imagine them. I won’t label any of them (even though stereotypes contrary to opinion are useful for making decisions) – there is variation within each language but in general, you hire a java programmer and you can expect different java programmers to see the world in similar ways, same goes for php, same goes for Ruby. They point out the valuable insight that choice of language should not solely focus on variables of performance, scalability, learning curve, etc – but should also take into account the “philosophy of the developers that work in this language” variable.

On code debt – Just reiterates the importance of refactoring in building an application iteratively. You make concessions along the way, calculated tradeoffs in the interest of getting working software earlier but if you let the “broken windows” pile up then you can bankrupt your application in code debt by having many tiny shortcuts lead to poor morale and bugs.

On reaching mavens for a successful launch – Malcolm Gladwell calls them Mavens, Seth Godin calls them Sneezers, the guy we rent office space from calls them Igniters – whatever. The point is if you’re launching something new and trying to get it to “tip” and cross that threshold of adoption where it spreads on its own, you need to focus on things that empower the alphageeks to spread the word more easily. This includes educational pro-bono stuff, spiffy features that people talk about but are still consistent w/ simplicity of the app, and mostly by focusing on creating something valuable for a niche of people. A market is by definition “a group of people that will potentially buy your stuff and reference each other.” This trait is key and 37s recognizes perhaps better than anyone else how to drop teasers on their blog and create a loyal following. Companies that are now paying employees full-time to simply write blogs that regurgitate the marketing messages from their websites are _completely_ missing the boat on how to reach mavens.

On their philosophy of karma, teaching and “pay it forward” – couldn’t agree more- this is at the heart of Grid7 and we are committed to bubbling up the lessons we learn in our experiments back to the community that supports us. Whether you consider this type of effort purely altruistic and karmic or as a pure, calculated mechanism for getting exposure for your stuff, it’s effective. Either way it’s something we’re committed to and are already doing to some extent by exposing our internal “tagging” of topics of relevance on the G7 site.

On ideas vs. execution – spot on. We’ve said it before and I’ll say it again here “ideas are a dime-a-dozen, it’s the execution that matters in the end.” When people express skepticism at sharing their ideas on the Grid7 application or companies seeking VC investment try to have their potential investors sign an NDA prior to sharing info- we say “bleh.” You can have the greatest idea in the world with poor or zero execution and it translates to nothing. Conversely, you can have a mediocre idea with enlightened execution and it’s definitely worth something just for the way in which its implemented.

I’ve been reading quite a bit lately and plan to share thoughts on some of these other works when time permits:

  • Guy Kawasaki – Art of the Start
  • Seth Godin – Purple Cow
  • Jim Collins – Good to Great
  • Ewing Marion Kauffman Foundation – Fasttrac TechVenture
  • Rhonda Abrahams – Simple Business Plan
  • Thomas Pender – UML Weekend Crash Course
  • Dave Thomas – Agile Development with Rails

© 2005 Lights Out Production – All Rights Reserved Worldwide

Mar 26

is a fancy term for the phenomenon that explains the bystander effect. I first learned about it a year ago when I read a book written by a local ASU professor called Influence: The Psychology of Persuasion. Of all the interesting ideas in that book, I’ve seen this one confirmed at least weekly in my own life and as recently as yesterday. In an emergency situation, understanding the concept of pluralistic ignorance, the bystander effect and how to slice through them could prove life-saving.

The extreme example that illustrates the concept of pluralistic ignorance (PI) is the 1964 murder of a woman in NYC. This lady was stabbed to death in broad daylight over the course of two hours and the act was witnessed by no less than forty bystanders, yet nobody did a thing to intervene. Understandably, there was a huge stink in the media following the murder- "how could forty people let a gruesome event like this occur in plain view?" The conclusion at the time was that clearly society was in decline and people were simply becoming apathetic to others’ problems (?!?). Subsequent research, however, supported the PI theory that in situations where one is confronted with uncertainty, he/she checks the reactions of peers for cues on how to respond. When other bystanders exhibit calmness, the observer that thinks he/she is the only one who finds the situation disturbing reserves those doubts internally and expresses false calmness to fit in. Strange self-feeding anomalies like the NYC murder can occur because this "groupthink" pseudo-acceptability perpetuates itself amongst observers and actually strengthens the effect as more people join in.

Just yesterday in boarding a SWA flight on my way home from Lake Tahoe I experienced this effect firsthand. I was engrossed in the final pages of the latest Michael Crichton thriller and had missed the announcement for my section to board the plane. It was a full flight and when I looked up there was still a ton of people directly in front of me and I couldn’t be sure if my section had boarded already. I grabbed my gear and rushed to the group of people in front of me if they had already called the "A’s." About eight people must have turned around and just stared at me- not one person responded. It was an awkward moment returning the blank stares of these folks. Remembering the PI effet I raced over to a different line and singled out one guy and asked the same question. The people with him turned first towards me and then towards him and he immediately responded that they had in fact called the A group already. While this was clearly not a life-and-death situation, it does demonstrate an important lesson:

My TakeawayIf you ever find yourself in an emergency situation and need immediate help from a bystander, resist the temptation to call blindly on a group of people for assistance and instead meet the gaze of one person, single that person out and call upon them for assistance within earshot of the others. Intuitively it would seem that the shotgun approach of calling on a larger group would yield more likelihood of grabbing someone’s attention, however, it has the opposite effect of setting stage for this abdication of responsibility to occur. By singling one person out publicly, you put the PI effect to work for you and create a situation where that person is now center stage in front of the others and at the very least will respond with concern and consequently generate more concern in the observers. This causes a self-feeding positive spiral that you want to occur. What’s interesting is that there is this focal point that is the reaction of observer #1 that is the fine line between a downward spiral towards complete apathy of the other bystanders vs. an upward spiral of a convergence of many people trying to help. If there’s a side you want to err upon in a crisis it’s clearly the latter and understanding the PI effect can be critical towards creating that response.

© 2005 Lights Out Production – All Rights Reserved Worldwide

Mar 15

Quicktime Virtual Reality Panoramas are immersive scenes that show a 360deg view of one’s surroundings. There are high-end solutions for creating these scenes that utilize special optics and tripods but you can also create a decent one using the digital camera you already own. I’m down in Mexico once again working from the road and enjoying spring break. My buddy Dave has a beach house here in Rosarito and a few of us shot this QTVR last night from his rooftop:

Here’s the simple recipe for how we did it using my Canon SD550 digital camera:

  1. Setup the scene – You’re going for 30deg separation on each shot – you need a way of aligning the scene so you can shoot 12 images equidistant around the “clockface” where you are standing. If you’re in sand you can actually draw a clockface on the ground and align each shot on its corresponding numeral, otherwise you’ll need to find orthogonal objects to give you a reference for the “12, 3, 6 and 9” positions and estimate 1/3rd the distance between each for the intermediary pics. I was standing on tile so that made it easy.
  2. Shoot the pics – the goal is to produce a sequence of images in perfect vertical alignment with a minimal change in brightness amongst each pic. Hold the camera vertically, focus and shoot one pic on each of the twelve numerals of the clockface. If you’re on a slope, you want the camera perpendicular to the sky and not to the slope (if you position relative to the slope you’ll end up with a QTVR that looks like a sine curve). I generally disable the flash unless there’s bright sunlight raking from an angle and you need to compensate for the objects in shadow. You want to hold the camera at the same vertical height as you spin around.
  3. Produce the movie – there are tons of options but I found a $70 shareware windows app called Panorama Factory by Smoky City Design that does an amazing job of intelligently splicing the photos to produce the final scene. Import the twelve photos you just shot into the program and follow the cues in the wizard using all the standard defaults. You’ll need to rotate your sequence of images unless your digital camera does this automatically for you – Panorama Factory has an option on import to do this automatically. You’ll step through a series of about 6 screens on the wizard and arrive at a point where it lets you save the final image. Choose the QTVR option and jpg compression and adjust the slider for quality depending on the delivery format (CD or Web) and how small you want to make the final file.

That’s it. Once you perfect the process of creating the QTVR, try experimenting with the advanced hotspot features to create a series of linked scenes that make a full virtual tour. Some camera vendors bundle QTVR software with their products – it’s probably a good idea to check the software that came with your camera before buying anything extra.

© 2005 Lights Out Production – All Rights Reserved Worldwide

Tagged with:
Mar 06

I spoke at the Refresh Phoenix meeting last night for an audience of about 25-30 people. We talked about the traditional paradigm of work in the corporate enviornment, the flaws associated with it and what Grid7 proposes to solve these. I posted my scratchpad outline for the talk here so you can skim the content. I taped it using the iPod and made the audio available below. The questions are a bit difficult to hear since we didn’t use microphones but all in all it seemed to be received well and generated a lot of discussion afterwards. Thanks to everyone who attended and asked questions. You can listen to the audio here.
© 2005 Lights Out Production – All Rights Reserved Worldwide

Mar 03

Most self-improvement programs suggest that the first steps are to:

  1. write down a list of your short-term and long-term goals
  2. post them in a conspicuous place

Doing this puts several things to work for you: First, when you write something down, the act of writing itself causes your brain to use different neural pathways. Odds are you could care less about which neurons you use to get something done, but you’d probably be interested to know the effects that research has shown writing to have on memory, cognition and creativity. Additionally, when you write your goals down you are forced to quantify and qualify them in ways that do not occur when you simply think to yourself “it’d be nice if i could do xyz someday…” Writing out the goals generally requires that you to think through the path towards achieving them as well. It gets you 100% clear on your intent (the “why”) and that is the strongest motivator you can possibly bring to bear. Anything you want to improve, you must first be able to track- this exercise clarifies exactly what you’re tracking from now on. The last thing you enact by exposing your goals publicly is peer pressure- when you post them on your bathroom mirror or on your bedroom wall or even in your cube, you tap into the same advantages that come with having a workout partner at the gym (ie. thinking to yourself, “i can’t skip today because i’ll be letting so-and-so down”). Peer pressure is typically conceived as a _bad_ thing but in this context I would argue that having other people aware of your goals will compel you to take steps necessary to meet them that you otherwise would not have. Posting goals in your workplace is a start but there’s a better, more conspicuous place to post them…

So in a bit of a social experiment, I’m proposing a meme centered around exposing your goals publicly for the next year and beyond. At the very worst – it’s comedy, you miss the mark on everything and nobody remembers the post a year from now. At the very best – it’s a living post that changes as you attain goals, an exercise that is the catalyst for some greater focus, and a neat way to peer over the fence and see what is important to other people (and prod them towards reaching their own goals). If you choose to participate, this is what you need to do:

  1. post a list of your short-term and long-term goals on your blog and mention who tapped you for the experiment. The goals you list don’t have to be technology-specific or anything-specific really- just stuff you want to want to eventually achieve. Aim high here, really ponder what you want to achieve someday, what you want your life’s work to be, and then write it down. Try to make the list as close to the chronology as you see it playing out- make it so it starts with the most short-term/atomic/realistic goals and let it wander to the most ambitious / wacky / long-term dreams
  2. use the title “opensource goals meme” so that other people can do a search and find the other participants. copy these instructions somewhere in the post or refer them here
  3. tap 5 friends to do this exercise after you are finished and actually READ what they write and REFLECT how their priorities are similar and different from your own
  4. maintain this list as you go crossing off things as you achieve them and adding new ones as they develop

So my list is perhaps a bit on the exhaustive/ambitious side but it’s been building in my Treo over the past year:

learn decision tree analysis
get accepted to the 9rules network
learn how to kite surf
learn to paraglide
learn morse code
reconnect w/ old friends on working US roadtrip
down-size, consolidate and turn house and convert to performing asset
get back to single-digit bodyfat
organize barcamp phoenix
regain flexibility
work for myself
cook 90% of all meals- less eating out
grid7 retreat w/ core intellectuals @ tonto natural bridge
achieve 1000 WPM reading speed
write for a reputable publication
learn yoga
become an employer
learn krav maga
buy a beachfront condo somewhere tropical
play “Panama” live on stage w/ Van Halen
take the bob baunderant school of racing
hold summer “cabin codefest”
produce coldturkey’s next album
get scuba certified
build a home recording studio
create a revolutionary billion dollar company
make the homepage of slashdot
drive from alaska to chile (fireandicetour)
learn to surf
make the “backs of giants” mural
learn accounting principles & tax law
learn tai chi
publish a kid’s book
learn to fly a helicopter
liberate 100 people from shitty jobs they hate
take down a major bully
develop a highschool curriculum
learn handwriting analysis
do a wilderness survival school and survive 1 wk in wild
start a VC firm
study all the major world religions
read all the Great Books
travel to all 7 continents
launch VELA project in phoenix
serve abroad in the peace corps
learn feng shui fundamentals
summit large mountain
speak at a major conference
complete the chronos custom nutrition program
complete a marathon
earn para3 rating and fly torrey pines
make the cover of WIRED
earn a PhD in biomimicry
beat the champion level of scrabble
meet the Dhali Lama in person
raise a child
x-country paragliding trip in either chile or australia
win pulitzer
redistribute the wealth based on merit
visit outer space
find cure for a major mental illness like depression
earn nobel prize

Ok, so granted they get wildly ambitious towards the end ;-) but my friend Don always said “goals are dreams with a deadline.” Never stop dreaming big, right?
Kimbro Staken, Steven Harvill, Rob Brooks-Bilson and Chris Tingom – you’ve been “tapped” ;-)

UPDATE: a few more people I’m tapping on this meme- John Blayter, John Bland, Max Porges, Noah Kagan, Francine Hardaway, John Murch

UPDATE: 6/16/06 – Held Cabin Codefest in Munds Park.

UPDATE: 8/1/06 – Became an employer (hired Ben as our first full-time employee)

UPDATE: 10/15/06 – completed the PADI scuba class

UPDATE: 12/15/06 – Got accepted to 9rules and organized the 1st Barcamp Phoenix

UPDATE: 1/5/07 – Had my first kite surfing course – woohoo!

UPDATE: 3/9/07 – Published my first book

Mar 02

This is just too awesome to not post- I was in a Japanese antique store yesterday getting some furniture for our office and I saw some of those clangy metal spheres you twirl in your hands that supposedly help you relax. After reading the instructions I had to buy them:

Dude, you had me at "Dalls."

A funny site that aggregates these kinds of mis-translations is Engrish.com– check it out.

preload preload preload