Agile Animal Inc.

So you are running Passenger with Apache2 and all of a sudden your server is not happy: Internal Server Error!

You look in the log file and you see: 

Error during failsafe response: closed stream
(originally closed stream)

Good news, all is not lost, it is your fault and you can fix it.

If you are dumb like me you ran a migration as "root" which means that your apache2 account can no longer open up the rails production.log file. (Or you did something else to mess up permissions.)

Fix the permissions and all will be better (after an apache restart of course).

Good news everyone…

Last year Rackspace acquired pretty much every single cloud computing company that I like in one swoop. Included in that list was Slicehost - cloud based virtual private servers.

Today Mosso (another of the acquisitions) turn up their Cloud Server service.

It took me about 5 minutes to get a Cloud Server up and running. Most of that time was spent typing details into their form and then adding the passwords to my vault.

The pricing is the best part. You only pay for what you use. It is really cost effective.

Once I have a chance to push the service a bit and once I get my hands on their developer APIs I will be able to give a better assessment - but I like what I see!

 I like getting paid.

I am not saying that I go to work for a paycheck - I love what I do - but a person has to eat and to eat they need to get paid.

For this reason I suspect you like getting paid too.

This is not a bad thing. It simply creates the reality that someone is going to have to pay for all the work that you do in a day. We call that person the customer. Whether the customer is a larger company or 100,000 teenagers they are going to have to pay for each line of code that you develop.

The truth is that this actually creates a simple answer to a complex problem. Often when developing software it is hard to know where to draw the line when it comes to features, documentation, etc. People often debate this for hours. It is actually pretty simple:

Make sure the customer is willing to pay for everything that you do.

It turns out that this actually can be broken down into two categories of user stories:

• Stories that have value so the customer is will to pay for them. (this might be that new feature you are working on.)
• Stories that have no value but are required to get paid. (this might be the documentation needed to use the new feature.)

Think of this as working and filling out a time sheet: you need to work to get paid and you need to fill out your time sheet to get paid. Valuable stories and required stories. Pretty simple.

In Scrum this simple concept forms the basis for a product backlog. The Product Owner (a representative of the customer) and the ScrumMaster make a list of stories and then assign a value to them. The team then estimates how hard a task will be to complete - lets call this the effort. Sort the list by dividing the value by the effort. Again, simple.

Priority = Value / Effort

Things only get a little tricky when we talk about required stories (the ones without value that are still needed to get paid). These should be kept up to date with the progress of the project. For example, a required manual should be updated once a feature is demo’d. This way the product can be released as needed with little notice.

As you work through the list you will eventually realize that at some point the value returned by a stories does not pay for your development costs to produce it. This is when you wrap the project up and deliver it. Again, simple.

So to recap here is the way to prioritize your work:

• Only work on stories that get you paid:
  • this can mean stories with value or
  • this can mean stories that have no value but are required.
• Don’t work on anything that is not required to get paid.
• Priority = Value / Effort
• Sort your list by priority.
• Even thought the priority of a required story is essentially zero, keep required stories up to date with your current progress so that you can deliver the product as requested by the customer.
• The project is done when the customer is happy with the current features or when it will cost more to develop a story than it is worth to the customer.

Follow these rules and you will get paid.

And you will be happy.

And your customer will be too.

Start small. Think BIG.

I read a book by Seth Godin a while back called "The Dip." (Well, by read I mean I listened to it after buying it from Audible.) The book gets a bit repetitive but the message is relevant. It is a book about quitting as a technique for success.

I am going to repeat that for those of you skimming this post: "The Dip" is a book about quitting as a technique for success.

Initially this should seem strange. For some reason society seems to think "winners never quit." Society is wrong. Winners quit. They quit so quickly that you might not even notice they tried at all. That is the whole point.

In my post on Prioritizing Work I talk about how we need to work from a backlog that orders stories by value. Most often you will find that the high value items are usually difficult. A difficult item with low business value is something that likely will never be done - why would you waste time working on a problem that has no value. At times you will find that a projects success hinges on completing some difficult items. They may be so difficult that , for many reasons, they are impossible and the software project is doomed to fail. That is why we need to build these features first.

If a software project fails after one week, great! This is the best possible way to fail: very little time and effort invested. Chances are there is disappointment but everyone survives.

Software projects that take years to fail bring down companies. I have personally seen it happen.

The only thing better than failing quickly is succeeding quickly. What better success to start a project with: tackling the hardest problem!

In XP they would call this a spike solution. In Scrum this is the way we organize our backlog. Either way the concept is simple: don’t invest time and effort into a project that you cannot finish. 

Failing early is the key to success.

I realized that this really answers a simple question and then presents a much harder one. Namely, you need to know if the problem you are working on is hard or if it is impossible.

I don’t have the answer for this one. There is no sure-fire way to measure your talent or that of your team and know if you will succeed. Analyze the problem. Be realistic about the availability of the resources need to complete it. Think about what is needed to succeed. Is success possible. Weigh the risks and rewards.

It is hard to predict success and failure. That is not what this is about. It is about honestly evaluating if success is an option and if failure is inevitable.

If you can’t succeed, fail quickly. 

Start small. Think BIG.

 According to a recent post on Engadget Mobile 91.2% of all iPhone users chew through less than 100MB of data in a month.