Making Decisions

The New York times has a great article about Making Big Decisions. Here's a nice summary:

Don't limit yourself to a single option. Simply by expanding your options you are 66% more likely to view the outcome as a success. The best way to expand your options is to diversify the group of people who have input.

Build stories for your multiple options: One where things go right, one where things go wrong and one where things go weird. Normally we build a single narrative, but by making multiple narratives we have a chance to figure out where things might go wrong.

Last, create a value model. List the values that are important and give them a score from 0 to 1. Then go through your three scenarios and grade them against your values in 1 to 100. Multiply the values to the scenarios and add up, the highest score is the one that fits you best.

5 Alternate Uses For GMail

GMail is the ultimate email client. Humorously, the capabilities that are so great for email actually enable several other "features".

1) Note taking - Any time I think of something interesting that I may want to remember, I write myself an email with the subject starting with "howto:". A couple that I visit often are "howto: make SEO work", "howto: deal with meetings" and "howto: amuse users while they are waiting"

2) Bookmarks - I never could get into sites like del.icio.us. Something about going to another site to create a bookmark just didn't make sense. I tried to use the bookmarklets and the browser plugins, but nothing made sense. Then one day I searched for a note that I knew had a link in it because I wanted to find the link. That was when I started sending emails to myself with keywords in the email to help find the link.

3) To do's - To do's are just short lived notes. I almost always delete them after they have been completed. For some reason actual to do lists or to do list software (web based or fat client) just doesn't work for me. I have started to believe that I have to-do-list-ophobia. But if I send myself an email then I am impacting my zero inbox beliefs so getting that to-do email out of my inbox is a priority. Also, I am always checking my email so the to-do is always available, whereas if the to-do list is in software, I have to actively go looking for it. To-do's even have their own tag with the most annoying color combination.

4) File transfer - I can't count the number of times I have used GMail to transfer files from one computer to another. I have emailed songs, books and of course word documents. This "feature" may seem weak, but I would argue it is so strong that you don't even know it is is a feature. You just expect email to send files. Heck, when Gmail came out one of the first things people tried to do with it was put a file system on top of it. Of course everyone is using dropbox for this now, but I still use GMail from time to time.

5) Tell me about your alternate uses for GMail!

Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.

Getting Creative

My son and I were having a conversation about some of his writing the other day. I told him that he needed to be more creative in his writing, and one of the best ways to do that is to give yourself constraints. Here is a great article about why constraints are a great way to get creative:

Next, creativity is all about connecting things. It is about knowing x and knowing y and then figuring out that if you put x and y together you will have something awesome. Often x and y are completely unrelated, but just knowing them helps. That means you have to start to learn lots of x's and y's. And they don't really need to be anything in particular, just... learn.

Open your mind to consuming information. And practice. Then put yourself in a position to create something and then CREATE! And do it by giving yourself constraints and using things that you already know.

Getting Started with Rails

A friend just asked me how to get started on Rails. I thought I would share my thoughts with the world also:

First, buy the books from the PragProg guys:

• Programming Ruby
• Agile Web Development with Rails
  

Don't worry about getting the Programming Ruby 1.9, it has another 6months to a year before it will be the preferred way to go. The community hasn't shifted to it yet. Just be aware that it is coming. Both of these books are must haves and really the only requirement to get started.

Second, I highly recommend buying a Mac or installing Linux. It can be done on Windows, but it just isn't fun. There will be a ton of new things that you are going to have to learn and being on a Mac usually gets you answers faster because so many people are using them. And the majority of the screencasts are on Macs. This isn't a must, but it will make your life easier.

Third, watch screencasts at PeepCode

• Start with Rails 2 from Scratch (there are two)
• Then do the REST Rails series
  
• Then learn about Git
  

You can skip the PeepCode screencasts if you don't want, but I feel like they are the best way to get started. Be sure to buy the pack of 5, it will save you $10.

Git is a distributed SCM and is really important. Everything in the community is moving to it. Rails is hosted on GitHub as are most of the libraries that you will need. If what you are doing is open source, then using GitHub will be free. They have excellent documentation to learn about Git on their site.

Fourth, watch more Rails Screencasts. These are free. Basically, you will want to search to see if he has answered a problem you have.

Fifth, bookmark the RailsApi. This is the best Rails API site I have found.

Deployment is going to be pesky, but I highly recommend Heroku. To deploy, you just push your git repository to the server and they take care of the dirty work for you. It is awesome. And brand spankin new... So there are times when it has issues but they are usually resolved rapidly.

Subscribe to the Rails talk mailing list. A good resource when you have questions.

I hope this helps a new Rails developer get started!