Robby on Rails

My fiance keeps pointing out how annoying it is to see science grouped with technology on the Google News site. (see Sci/Tech)

Why is this annoying? Well… take a look at the following screenshot.

What doesn’t seem like it belongs in this list?

If you guessed, “Dwarf dinosaur fossil found in Germany”... you guessed right!

I wish that they had just a Science category as I hardly see how this needs to be grouped with news about Nintendo or new voip phone applications.

Picking up on my last Borat post, Prototypes Are Your Friends, I would like to direct you over to the next post in the series, G’day Project Borat where Brian Ford jumps into the game…

“When we, as developers, began focusing on user-centric design and usability, it was a recognition that users deserved respect and need not be rescued, if you will, by our bright ideas. In a big way, we needed to keep our bright ideas out of the user’s way.”

Read more...

This morning, Brian Ford and I headed over to Powell’s Technical Bookstore to pick up their one used copy of Code Complete, 2nd ed. While we both stood there reviewing the contents, I felt somewhat unsatisfied with the purchase that I was about to make. It then occurred to me that what I was looking for was quite different and while the programmer side of me felt the need to make the purchase, there was another void to fill. Requirements gathering, prototyping, use cases, and delivery are areas where I am really focusing a lot of my attention to. Brian and I discussed how Test-Driven Development solves some of the problems surrounding application development and Behavior Driven Development might pick up on some of that slack as well.. but what about the stuff that happens prior to sitting down to code these units of work? How do we define them? How do we extract meaningful requirements from the client and allow them to participate in a sign-off process where they confirm that they are confident that you understand what their problem is and that you have a clear picture of a solution? These are questions that I have been trying to answer for myself.

While talking with Brian during our walk to and in the store… a random Delphi developer that struck up a conversation with us about the Code Complete book we had in our hands and XP methodology. While listening to him, I noticed a book title, Mastering the Requirements Process, 2nd ed., which I picked it up and glanced at the table of contents and noticed the title for Chapter 5, “Trawling for Requirements.”

”...in which we drag the net through the work area looking for requirements, and discuss some useful techniques for doing so”

I was immediately drawn to the book at that point and decided to purchase up both books for the PLANET ARGON library. It’s written by Suzanne and James Robertson and published by Addison Wesley.

The book describes this figure with, “The overlap between Requirements Gathering and Systems Modeling varies as the development of the product progresses. Initially, very little modeling is done, and the majority of the effort focuses on gathering and verifying requirements. As development continues, the modeling activity expands to occupy a continually greater proportion of the effort.”

I’m really looking forward to diving deeper into this book and will share my thoughts on Requirements Gathering and how we’re doing it at PLANET ARGON. :-)

I came across a review of Code Complete, 2nd Ed. last night… and saw the following quotes.

””People have already made all the mistakes that you’re making now, and unless you’re a glutton for punishment, you’ll prefer reading their books and avoiding their mistakes to inventing new versions of old problems.” “

...and

””Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity.”“

I’m sold and with 900+ pages… I’m sure I have a few things to learn. I’m going to go pick it up shortly at Powell’s Technical. :-)

I’d like to apologize for not keeping you updated on Project Borat. If you’d like some background, please read Project Borat, an introduction.

“In early stage design, pretend the interface is magic.”[1]

We’re finishing up Iteration 1, which is a prototype and requirement feedback process. When I used to be a house painter, we’d spend time painting small samples for the customer. The customer would come by when the paint was dry and compare the colors to what they had pictured in their mind and once there was an agreement, we’d move forward with purchasing the necessary quantity of paint for their house. Thinking back… I never questioned this “Show them samples” process as it was how the company did business… but now it seems obvious that people must that made many mistakes of buying colors that weren’t exactly what the customer wanted. Then the painters would be required to repaint. Development work resembles this and this is where prototypes come into play. Painting a house is not quite like developing an application… but that reoccurring process of encouraging customer feedback as early as possible is very similar. It is this feedback that builds confidence that you understand the customers desires. However, if you end up with too much of the wrong color of paint… you might be able to paint a few dog houses with it. ;-)

Over the past few weeks, we’ve had several meetings with the Client to discuss prototypes, user interaction, and goals. For example:

• When User does X, what information should they be presented with?
• What types of users will use this application?
• What are some of the goals and intentions of the users?
• Might a user want to do z before x?
• Are users interested in doing something completely different?

During this Iteration we also hit a major milestone for the client. For the first time since they came up with their idea, they were able to see something visual and had semi-functional to play with. The prototype resembled what they had been thinking about conceptually for several months. It can be easy as a developer to forget the importance and excitement that goes along with seeing something that consolidates your ideas… visually for the first time. This process requires a good stream of feedback and asking specific questions about functionality possibilities and not burdening the user with too much information in certain contexts… while still providing them with enough to keep them interested.

In The Art of Project Management, Scott Berkun raises the following questions for iterations and prototypes.

• What requirements does this satisfy? Can we verify this? (Usability, use-cases, etc.)
• What’s good and bad about this design relative to the problem it’s supposed to solve (Pros and cons for each of usability, business, technology, considerations.)
• What data do we need to evaluate this design? (Perhaps a usability study, an informal review by a programmer for engineering sanity, marketing, an expert’s opinion, etc.)
• What did we learn from this design that we should keep in the next attempt? Eliminate?
• Are there any other idea groupings or from other prototypes that we should include?

Another important thing to do during any iteration is to keep a list of open-issues. Berkun suggests using a simple tool for this. We’re using plain text files in subversion and using Textile for markup.

What’s next?

• Idea consolidating
• More prototypes
• Discussing architecture plan
• Scheduling

Until next time…

¹ Alan Cooper & Robert Reimann, About Face 2.0: The Essentials of Interaction Design. Wiley 2003.

Jacob Harris, a very nice guy that I have the pleasure of chatting with online almost every day during the week. Not only is he a hosting customer… he’s my East Coast buddy that I hope to meet in person for the first time in a few months… should he make it out to Portland for OSCON 2006! The PLANET ARGON team loves harrisj!

Earlier this evening, I noticed that today he wrote a blog entry titled, Are You Happy?

He gives a good introduction into something that I actually had not heard of before… Flow.

Jacob says, “Trying to find happiness through artificially increasing productivity is like putting the cart before the horse.”

...trust me… read the post. :-)