browngeek

Status reports are a pain in the arse to write. And doing it every week? Fuggedaboutit.

As you would expect from a geek, I decided to code my status reports. I have mentioned earlier that I use Basecamp for project collaboration. The Basecamp API was released a few weeks ago. And Quirkey has a PHP wrapper for the API. Sweet. All I had to do is decide on what stuff to include in the report and the design of the report itself.

The result: a nice-looking report that is rendered automagically every week.

The code: PHP wrapper for the Basecamp API, PHP code for the report, CSS for the report

How Yahoo! will beat Google? By employing Scrum of course!

Read the article comparing Yahoo! and Google -

Yahoo says it is now trying to emulate Google’s faster method of creating products. Like most big companies, it used to develop software by first creating a comprehensive design that defined how features would be written and tested. Instead, it is now trying what is known as a scrum method, where it will plan, build and test parts of a product every 30 days.

“We may not know how everything fits together,” [Ash Patel, Yahoo’s chief product officer] said. But by creating partly completed products that can be shown to customers, “We can get insights from users and react to that over a three- or four-month period to put it all together,” he said.

Being Agile is the only way to beat your competition and, more importantly, building products that your customers really need.

Jeff Bezos might finally bring AMZN to profitability. How? He just invested in 37Signals, the company that makes the amazing project collaboration app Basecamp. I have written about the awesomeness of Basecamp. I used it religiously everyday. For Scrum iteration planning, iteration tracking, as a burn-down “chart” etc etc. My team clearly sees the advantage. It gels the project together. (I also use their Backpack for my personal projects. And yes, its equally awesome. And yes, I am a 37signals fanboy).

Now, I only hope Bezos leaves the boys there alone. Basecamp’s strength is in its simple, uncluttered interface. Certainly don’t need Amazon’s shove-it-all-in-a-page influence there!

The MasterChief in Halo3 may very well be *exactly* the way you want Him. That is because He might be developed using the Scrum method of agile software development. Checkout the excellent article on Gamasutra titled “Paper Burns: Game Design With Agile Methodologies”. It articulates the huge advantages of Scrum over the traditional Waterfall method.

The article nails the problem with the Waterfall model (shown above):

The traditional methodology, often called Waterfall, isn’t dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish. The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn’t end up to original specifications. Factors like these are what degrade product quality.

An assembly line might work well for hardware development where the design is made once and there is hardly any change beyond that. OTOH, software development has twists and turns at every possible moment. An assembly line (Plan-Plan-Plan-Design-Design-Design-Code-Code-Code-Test-Test-Test) is too rigid and linear a process to deal with the changing requirements in software (game or enterprise).

Scrum (shown above) advises an iterative non-linear (Plan-Design-Code-Test..Repeat) approach for software developement. In each iteration, every team, Designers, Developers, QA, Doc and Prod Mgmt has a say on the progress. This makes a true team development and ultimately a product that is exactly what the market wants. Non-linear over linear.

One obvious advantage of iterative development is the chance to innovate at every iteration. This is possible because of the non-linear approach where there is room for innovation during the Plan and Design phase.

Conversations are initiated, questions are asked, dialogue and cross department problem solving occurs organically. Assumptions that lead to wasted time and effort are checked at the door, and a collaboration can be reached that gets the best game out in the most efficient way possible.

The other not-so-obvious outcome of iterative development is the blossoming of true teamwork. The triumph of Courage over Fear.

A QA engineer joined my Scrum team today. He is an experienced engineer and is well respected. The problem is though, he is entirely new to Scrum. His whole career has been in following the waterfall approach to software development.

So the first thing he asks me is “Where is the functional spec?”.

I say - “We have a living document that we update every Sprint iteration.”

He asks - “But how can you write code without a functional spec?”

I say - “Because we don’t know all the requirements yet. We are writing code for the requirements we know so far. When more requirements come, we will factor them in the next iteration.”

He - “You mean you don’t have a design spec!”

I - “No. We rather produce working software that speaks for itself.”

He - “But what will you do when new requirements come in? Change the design?”

I - “No. But we will refactor when needed. That is normal anyway. Even if we did write a design spec, there is no way we will know all the classes we will ever write for the whole release. Instead, we simply whiteboard the design when needed and write code.”

He - “But how will I write the test cases? I need to see the functional spec to write them.”

I - “Do you really only look at the functional spec to write your test cases?”

He- “Well, sometime I also look at the design spec.”

I - “Really?”

He- “Only sometimes. Other times I look at the alpha drop.”

I - “You mean you look at the actual software to write the tests?”

He- “Yeah, we can quickly understand what the features are by playing with the product.”

I - “Good. You don’t have to wait until alpha anymore. We will give you a working drop every month!”

He - “…”

I - ” (smile) ”

Most people that are new to Scrum or any agile approach are very apprehensive about the lack of comprehensive documents upfront. They seldom realize that such documents only give a false sense of security (Its just a line item in the Great Master Project Plan ^TM). In each and every case, the final product will be a far cry from the what was proposed in the functional specification months (sometimes years) ago.

The thinking has to change. Fear has to disappear (or atleast hide). Courage has to occur.

The Agile Manifesto principles are

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I believe there should be a key fifth principle.

Courage to try over Fear of failure

I decided to give the SoonR service a try when I read Om Malik’s blurb about SoonR’s big day when they are launching their service for OSX. Great, I thought. I would love to access my MBP from my blackberry. That would be uber cool.

Well, I installed the SoonR for Mac today (which is in beta, of course). Installation was NOT so smooth.

• I was not given a choice for the destination. It installed directly in Applications. I hate it when installations do that. Sure, I can drag it to somewhere else after it installs - but thats the problem. Its after the fact.
• As soon as installation completed, a prompt came up - apparently there is an updated version already! Either the developers at SoonR are so super-productive that they spewed an update 40 seconds after I downloaded the version from their site, or they are plain lazy to *not* update their download page with the latest drop. Somehow me thinks its the later.
• So I click Ok to install the latest drop. Well, the installer simply hung. Forever. Turns out, the “older” SoonR was running. I had to ForceQuit it! Not cool.

Ok, after the ugly install experience, SoonR asked me to register. This step went smooth (hard to screw this up anyway). Then came the real litmus test. Will it actually work?

Turns out it will not.

SoonR stays in the perpetual “Connecting” state. It complains about username/password being empty - but they are not. Ok, maybe I should login from my blackberry to bootstrap the firsttime (Note- this is a guess, no troubleshooting info from SoonR. I even checked the logs!). The login from my handheld was fine, but it says my “Desktop” is empty. Also noted that the icons thats showed up in my blackberry were the Windoze Desktop and Outlook icons. No indication about my Mac install. Again, not cool.

This is really disappointing. I was so looking forward to using the service. I guess SoonR has all the hype but not much code to back it up - yet.

Well, SoonR, I’ll see you LateR.

The coolest widget on my MBP’s dashboard is the Sing that iTune widget. It displays the lyrics of the song currently playing on iTunes. And it just works!

I can finally understand what the hell Thom Yorke of Radiohead is singing. Oh its “gucci little piggy” in Paranoid Android {”Ambition makes you look pretty ugly / Kicking, squealing gucci little piggy”}.

Thank you.

Click on photos for the Lightbox FX.

With the arrival of my MBP, came the sweet revival of my love for making movies. Here is my first attempt at using the amazing iMovie.

The footage is from my first marathon - The 10th Pacific Shoreline Marathon. I ran a sub-4hr marathon. It was the culmination of 16 weeks of iterations…I mean training And I am quite proud of it.