Ruby on Rails Planet

Hello, HeyBrainstormr.com »

Created at: 04.06.2009 02:28, source: Robby on Rails, tagged: Ruby on Rails PLANET ARGON heybrainstormr brainstormr launch brainstorming agile design development planetargon

If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)

HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.

We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)

what can i do right now? : Brainstorming for the rest of us. : HeyBrainstormr

We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.

Start a brainstorm now!

I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)

We hope that you find it as fun as we have.

What can we do right now? »

Created at: 04.06.2009 02:12, source: Robby on Rails, tagged: ruby programming Projects agile gtd team book programming inspiration motivation kindle

Last month I picked up a new kindle from Amazon and have been reading a handful of books. One book that I’ve been really impressed with is Chad Fowler’s new book, The Passionate Programmer.

I plan to post some more thoughts in upcoming articles, but wanted to share this gem.

“If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell. Create movement. Be the one who pushes. Don’t get comfortable. Always be the one to ask, “But what can we do right now?”” - Chad Fowler, The Passionate Programmer

Sometimes we feel stuck, but that doesn’t stop us from stepping to the side and assessing the situation. There is always something useful that we could be doing right now.

Building a prototype? Bring some rope. »

Created at: 09.04.2009 23:57, source: Robby on Rails, tagged: programming PLANET ARGON programming agile prototypes books quote development

While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services, I came across this nugget.

The problem with software prototypes
It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.

It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.

The author continues with…

It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.

I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.

Lessons through failure. Episode 1 »

Created at: 18.01.2009 01:34, source: Robby on Rails, tagged: Off-Topic programming coding failure fail productivity team programming agile

I fucked up this last week.

On Monday, our primary contact for a large client sent over some last minute requirements and deadlines that were needed by end-of-day Wednesday. I didn’t have a lot of time to collect requirements and execute it without having to rearrange my priorities. But, I accepted the challenge.

The big change involved was that we were going to be supplied with a ton of data to be imported in to the database and approximately 20% of the data provided was new records, while the rest were duplicates. However, the other 80% wasn’t to be discarded as there were a few attributes that needed to be updated from the data file (which was supplied from the client’s parent company). In my haste to get the task done on time (didn’t get proper export file to be imported in our system until Wednesday morning)... I ended up running a few tests locally and pushed it out to production.

I managed to get the import file to run in production before leaving on Wednesday afternoon. The following morning, I came into the office to find out that my import process didn’t match up records properly and resulted in nearly all of the 80% side of that to be duplicated in the system. This resulted in lost productivity for our client, their vendors, and our team over a 12 hour period as people were confused about why reports were running weird, online transactions didn’t account for the duplicated, etc.

It took me most of Thursday and Friday to clean up the data that got skewed due to that oversight. Hi ho.

So, the take away from this? Sure, I could have blamed it on a lack of sufficient time to properly test things, but that’s bullshit. I should have had at least one other developer from our team review the problem and evaluate my proposed solution prior to me attempting to push into production.

Luckily, the client was happy that we were able to finish the last minute tasks, despite the unexpected headaches that cropped up.

If anything, I was just disappointed in myself, but Alex reminded me how important it was to fail early, fail often. It didn’t kill me (or anybody else for that matter), cost us the project, nor was it irreparable.

In the real world, deadlines and requirements change on a moments notice and it’s experiences like this that will make ourselves more confident that we can quickly respond to and execute.

What was your latest failure?