Gary Haran.com

I had a really good experience last night with the Standout Jobs team. We had a hairy situation dealing with some new features. The difficulty was that we did too much magic for the end user and it simply didn’t flow from an navigation point of view.

We rarely have lengthy meetings (meaning anything lasting more than 10 minutes) but we spent close to 30 minutes last night trying to figure out the best way to implement things. In the group we had ruby guru, a design guru(more of a Design-Grammer), the CTO and I (a front end programmer).

First we determined what we weren’t doing right then looked at how other web applications approached similar features. The process we went through was very different than what you’d see in a company used to the waterfall model. One saving grace was that we didn’t have huge specifications to blindly follow. This meant we had to think and speak up about what the feature should look like. At any time we could be asked to explain why we implemented something a certain way.

Everyone on the team was open to suggestions even if it meant reviewing what others in the team had already done. Actually we know that everything we do is iterative and nothing is ever set in stone. It’s called the Agile and because this process has a name it’s easier to stand behind it.

After 30 minutes of arguing we settles on an elegant solution to our problem. We split one end-user action that did two different things at once into two separate end-user actions with each their own feedback. We changed the navigation to reflect those changes which made it clearer even for us. Though we didn’t change code during the meeting the resulting code will be easier to test. It’ll also be easier to change if we want to at this point.

A similar experience in company espousing the waterfall model will clearly result in so much red tape that most programmers would just give up and live with it. Imagine having to ask a manager to change his sacrosanct specification document. So many programmers are discouraged to even speak up in large enterprise that their improvements rarely see the light of day.

In a startup egos and job titles don’t get in the way of communication. Everyone’s input is valued and encouraged.