anml

Iterate 1.1.2 an iPhone App for Pivotal Tracker

markcm — Tue, 30 Nov 2010 03:03:00 -0500

Iterate 1.1.2 is Available in the App Store

Today we released an update to Iterate, our iPhone client for Pivotal Tracker.

This small bug fix to Iterate extends our timeout (or the amount of time that we wait for a server to respond to a request for information).

Iterate is great because right from your iPhone you can:

Access your projects on the go including your Current Iteration, Backlog and Icebox. (To access everything you need to turn on some goodies in settings)
Update the status, estimate or owner of a story.
Add a label, note, task or attachment to a story.
Mark tasks as being complete.
Add a new story to your Icebox.
Start a story in your Backlog or Icebox.

If you are using Iterate please check out the settings. We have turned off a lot of features that consume data to ensure that people with large projects don’t have trouble - but if your projects are smaller there are some goodies you can turn back on.

What’s Next?

At this point we’d really like to hear from people using Iterate to know what direction we need to take next.

We think we have the best app out there for accessing Pivotal Tracker on the go. But that’s just us. What do you think?

How can we make Iterate better?

Network Compatibility for Rogers

markcm — Fri, 16 Jul 2010 07:23:00 -0400

Rogers 3G/3.5G runs on 850/1900

No matter what people tell you about phone compatibility, you need both bands to be sure you will get full coverage. Full details on the GSMA website.

If you poke around you’ll see that Rogers also owns some 1700 spectrum. It is not in use at this point in time.

Also, the GSMA seems to think that Fido operates their 3G on 2100 but I am under the impression that this is not the case - they use 850/1900 just like Rogers.

The Punchline

If someone is trying to sell you an unlocked phone and you want to use it in Canada it needs to have the 850 and 1900 bands.

Nexus One WiFi Issues on Android 2.1 and 2.2

markcm — Fri, 16 Jul 2010 03:15:00 -0400

The Nexus One WiFi Issue

I read an article on BGR on users reporting WiFi issues with the Nexus One.

I actually am experiencing the issue - so let me provide some insight.

The Problem: Reconnecting to WiFi

When the Nexus One goes to sleep (turns off it’s display) the default behavior is to disconnect from WiFi - I assume to save power. When you wake the device back up it is supposed to connect to your WiFi network automatically. The problem is that this never happens.

The Nexus One gets itself into a state where is disables reconnections to the WiFi network and won’t try to connect again unless prompted: this can include rebooting, turning WiFi off then on again, or telling it to connect to the network.

Part of the issue seems to involve leaving the home-screen before WiFi connects. Could be coincidence - not sure.

Another potential coincidence is that I don’t seem to experience the issue at my office. Pretty much the same WiFi both places though, Apple AirPort Extremes. The only difference might be Airport versions.

This is Actually a “New” Issue

What do I mean by that? The Nexus One in question is actually my second and my original Nexus One did not exhibit this behavior. It would connect to WiFi without prompting.

This doesn’t mean it is hardware related. But it could very well be. Equally likely that a firmware issue can fix it.

The Solution

There isn’t one at this point short of installing a 3rd party app that reconnects you once your WiFi drops out.

Hope Google gets to the bottom of this one soon.

UPDATE

It appears to be a chipset issue after all involving the WiFi sleep mode and certain routers. It is also the case that it should be fixable in software.

Froyo on the Nexus One - this is the Droid you are looking for.

markcm — Sat, 05 Jun 2010 06:08:00 -0400

Android 2.2 Previewed at Google IO

Well, it was more than previewed - Google actually let it out into the wild for a bit where Nexus One users with the AWS version of the phone (think T-Mobile or WIND) were able to update.

The update has since been pulled (search and ye shall find, though) but I tossed it on my Nexus One and gave it a once over.

Tethering FTW

Android 2.2 adds WiFi tethering. This really is the killer feature, especially if you are packing a WiFi only iPad.

It is super simple to setup and works like a charm.

Flash Support (Not that I want it.)

Android 2.2 also adds support for Flash - not that I’d suggest installing it or turing it on.

Of the three people that cheered when this was announced, two work for Adobe and one makes CPU hogging Flash ads for websites.

GUI Updates

Google is starting to add a bit more polish to the Vanilla Android GUI. For example, quick access to your phone or browser is now available from the home screen.

I would expect this to be kicked into overdrive with Android 3.0 whenever we see it. Google has hired a key player from Palm’s WebOS team and I would expect that to significantly improve the look of the stock Android OS.

Nexus One and Android

The killer combo really comes from two things, hardware and software.

Hardware

If you have ever held a Nexus One you know the hardware is amazing. HTC really knows how to make a great phone that is sleek and sexy. The OLED display is the best I have seen on a phone.

Software

Android is the perfect OS if you are a GMail or Google Apps user. There simply isn’t another platform besides Android that does justice to GMail in a mobile environment.

The Punchline

When you combine great hardware with great software you win. The experience would be perfect if it didn’t look like Google.

Still No Flash on the iPhone. Why the Surprise?

markcm — Sat, 10 Apr 2010 02:50:00 -0400

Disclaimer

Look, I am totally making this all up. I have no idea what Adobe or Apple is thinking.

However, in my twisted imagination, this is how this whole Flash/iPhone situation went down…

I can imagine the conversation…

This is how I imagine the conversation going a couple years ago when Adobe first tried to bring flash to the iPhone:

ADOBE: So, how about adding flash support to the iPhone?
APPLE: Yeah, no thanks. We’re not really crazy about how it works on OSX.
ADOBE: Um, pretty please.
APPLE: Yeah, no.
ADOBE: What if we build a Flash cross-compiler that creates native iPhone Apps. That will be much better, right?
APPLE: Still no.
ADOBE: Well, just in case you change your mind we’ll build one anyways.
APPLE: Don’t call us. We’ll call you…

Why the surprise?

I am not sure why anyone, including Adobe, is surprised about the announcement. I cannot image a world where Apple would let this happen. They said “NO” to Flash on the iPhone browser - why would this be different.

This really is the main thing that gets me: I can’t believe that Adobe had the expectation that Apple would just sign off on this. I am going to assume that they new this all along. So then the real question is: why build and publicize a feature that Adobe KNOWS is going to be rejected by Apple?

And, why build something you KNOW Apple will reject?

Let’s pretend to be Adobe. Years of being on 99.9% of all browsers and then two things happen: Apple publicly denounces support for Flash on their Mobile platform (which is really starting to pick up steam) and people really start talking about Flash alternatives and HTML5.

That is not going to make you happy. iPhone, arguably the most advanced mobile platform ever, thumbing it’s nose at Flash. It is going to be hard to explain that one to the investors. Apple and Adobe have a difference of opinion on this but it is Apple’s closed device.

Well, if Adobe can’t convince Apple to put Flash on the iPhone, maybe public opinion can. So Adobe starts making its concerns public in an attempt to get support. And while a lot of people agree with them, a lot of people who are tired of Flash crashing their browser start talking about that, and suggest it was simply time to upgrade to HTML5 anyways. Poor Adobe, if anything now HTML5 has more support.

And this is the point where Adobe decides to build a tool that they KNOW is going to get rejected. If they show it off to developers and get them excited maybe this will be enough.

So they build a Flash-to-iPhone compiler and make it the tentpole feature of Flash CS5 in the hopes public opinion will sway Apple in ways that they cannot.

Days before they can launch Apple explicitly forbids the use of Flash. And the public reacts.

How will a Flash/iPhone compiler help me?

It won’t. The App Store is full already. It is bursting at the seams with Apps.

There may be some developers or publishers that have been waiting for Flash but they have other options. And while those options likely increase the complexity and cost of development they also encourage developers to make apps that are specifically tailored to the iPhone or iPad.

Most (if not ALL) of the time Apple’s tools will make a better App.

Won’t this help me as a developer?

Nope. It will just lower the bar. It will mean anyone that can use Flash can now publish an App. It will get more Apps in an already difficult to navigate store.

Differentiation is what allows you to charge for your App.

The harder it is to create an App the bigger the potential reward for those who do it.

Is this going to work?

Nope. And as far as I can tell it will likely backfire (if it was done for these reasons I imagine).

Steve Jobs isn’t the sort of guy that public pressure works on. He is driven by a purpose larger than public opinion. Apple is driven by this same purpose.

It is going to backfire because Adobe has inadvertently started a debate about the relevancy of Flash. And I don’t think they will be happy with the results. If I was a betting man I would bet on HTML5.

The Punchline

Why develop something that Apple will reject? Clearly this is a posturing attempt by Adobe to get more public support for their efforts to maintain the relevance of Flash.

And I think it will be later known as a tactical error.

Palm webOS 1.3.1 Released: what is fixed, what is broken.

markcm — Sun, 15 Nov 2009 07:40:00 -0500

webOS 1.3.1 Released

Today Palm released webOS 1.3.1. If you hit their support pages you will see a list of the release notes.

What was fixed.

I had personally reported several issues when if came to the sync of emails and calendars. With one exception (see the what is not list below) I think they have fixed it all. Not a moment too soon - I was ready to give up on the platform due to the email related issues.

In summary: + Email messages still push even when your account hits 50 messages (FINALLY!) + Calendars now still sync even with special characters and notes. + Exchange related issues seem to be resolved.

I have noticed that the platform is a bit more responsive in certain situations, but generally speaking the speed increases are not as dramatic as previously suggested. Applications still take too long to launch.

What was not.

I hear that iTunes support is still broken. I don’t use it myself so I can’t confirm this.

More importantly Google Calendars (for Google Apps accounts) only sync over EvDO. So if you want your calendar to update you will need to turn off WiFi and then sync. If forcing update doesn’t work try editing your account settings and simply type in your password again - this got things syncing again for me.

The Punchline

If your calendar won’t sync, turn off WiFi and try again. And don’t hold your breath for iTunes support.

Everything else with the platform should be fixed.

The Rogers HSPA+ Rocket Stick & Mac OS X 10.6 Snow Leopard

markcm — Sat, 10 Oct 2009 09:11:00 -0400

Zero-Install Plug and Play Software Doesn’t Mean What You Think…

Okay so before I get to the punchline I am going to rant. Sorry.

I am used to using Novatel Wireless devices and they have great Mac support. Many have drivers bundled with the OS so you just plug them in and type in the settings. Then you are on the web.

Clearly a Microsoft Windows user wrote this statement because on a Mac this means that the driver is bundled with the OS (and not on a hidden read-only flash drive on the device). Really, doesn’t Zero-Install mean you don’t have to install drivers. So when I plugged the Rocket Internet Stick into my MacBook and it didn’t appear in my network settings I was disappointed to say the least.

Making matters worse for some reason the Rocket Stick (ZTE MF668) didn’t even work once I installed the drivers. I had the following symptoms on Mac OS X 10.6 (Snow Leopard):

The bundled Rogers App does pretty much nothing. It tries to connect but always fails.
Once the devices is unplugged it is uninstalled along with any network settings preventing manual configuration.

The Game Plan

Having setup several different Rocket Sticks and similar devices I figured that the best option would be to manually configure the modem. That means we need to accomplish two things - first we need to disable whatever is removing the device from the network settings and then we need to create a manual profile.

To do this we need to get everything installed first then clean it up. First we will install the package that comes on the Stick. Then we will delete the LaunchDaemon that clears the settings and remove the Rogers App. Finally we will add a Modem profile for the Rocket Stick (ZTE MF668) and enter the Rogers network settings.

Installation

The first step is to install the provided drivers. They will mount (showing up as a CD on the desktop) when you first plug the device in.

Once this is done you need to remove the Rogers App (Connection Manager.app) and uninstall the LaunchDaemon that will keep trying to remove any created profiles.

cd /Library/LaunchDaemons/
sudo launchctl unload cn.com.zte.PPPMonitor.plist
sudo rm -rf ./cn.com.zte.PPPMonitor.plist

cd /Applications/
sudo rm -rf ./Connection\ Manager.app

Eventually you should see a popup where you can launch Network Preferences to configure the device.

Configuration

Now you are staring a the Network Preferences Panel. We need to do a couple things here to get things running. You need to setup the newly added ZTEUSBModem (you can safely delete the ZTEUSBATPort if you want - it is just needed for the Rogers Connection Manager).

First we need to type in basic settings:

Telephone Number: *99#
Account Name: wapuser1
Password: wap

The click the “Show modem status in menu bar” so you can easily connect.

The you need to go to Advanced Settings (button in bottom left) and click Advanced. Make sure you are on the Modem tab. Select Generic as the vendor, GPRS (GSM/3G) as the Model and type in internet.com as the APN.

If you want you can rename the USB Modem to something like “Rocket Stick” and you can reorder the service so that when plugged in this takes preference over other connections.

Using the Modem

At this point all you need to do is click connect from the Rocket Stick tab in the Network Preferences.

If you have enabled it you can also do this from the menu bar by clicking connect directly form there.

Final Thoughts.

Well, that might have been a little tricky or hard but, trust me, it will be worth it in the end. Rogers has done a great job of expanding their existing 3G coverage and I am looking forward to HSPA+ in Edmonton.

Palm Pre Workarounds and Troubleshooting Tips

markcm — Wed, 07 Oct 2009 08:30:00 -0400

WebOS

Let’s face it, as cool as it is, the WebOS is really a beta. It has been out for 6 months and has not been thoroughly tested. So things are breaking.

For me there were two major issues that were killing me:

My hosted Google Apps GMail would just stop working.
Calendars would just stop syncing.

After searching and hacking and playing I found the following four things fixed just about everything.

Four (plus One) Tips to Keep Your Pre Happy

Until the WebOS is fixed here are four tips that will keep things going with as few issues as possible:

Setup your GMail account in Calendar, not Email.
Don’t use ActiveSync - Use IMAP - where possible.
Archive messages out of your Inbox - keep the total count well below 50.
Only use LETTERS and NUMBERS in your calendar appointments.
bonus: If sync is not working disable WiFi and reboot.

Google suggests the first tip and they are right. The Pre will fill in the settings for Email when you add the account in Calendar.

While you may be tempted to use Exchange support there are some email bugs with it. I’d steer clear and use IMAP if you can. Hopefully this will be fixed soon - Palm knows about this.

If you hit 50 messages in your Inbox you are dead. No more messages will come. Keep your Inbox clean.

Calendar syncing WILL stop if you add things like a comma or even a question mark. Sad as it is only numbers and letters. This has been reported in Palm’s forums and I know that a bug has been filed as well.

I had trouble again with sync tonight and I found that in addition to all the other steps what really did the trick was a couple reboots with WiFi disabled. Not sure why this worked.

I Don’t Like Magic Fixes…

As annoying as these workarounds are I still like the Pre. It is the best iPhone alternative on the Market right now. I think the competition will be good for Apple.

That is not to say I am ditching my iPhone. But I do like the Pre.

Continuous Integration in 2009

markcm — Tue, 30 Jun 2009 05:10:00 -0400

A Great Idea

Continuous Integration (CI) is a really great idea.

For a guy like me it means that one week before a major product deadline I can leave early on Friday (as opposed to freaking out and working a 75 hour week.)

But, it doesn’t mean what it used to. Less that two years ago I remember talking about Continuous Integration as “Making sure someone doesn’t break the build.” Reading that statement makes me laugh now. What a ridiculously low bar.

Back then just having a server check out your code and compile it was something. Having it run unit tests the package your software for deployment was amazing.

Times have changed.

What I am now looking for in a Continuous Integration server it is completely different. I want it to grab the code and run Unit, Functional and Acceptance tests on it. Then I want a code coverage report for those tests. On top of that I want a report on standard code metrics that will tell me things like how “DRY” the code is.

To be considered exceptional all of these features need to be tightly integrated and status notifications about updates should be done over Twitter and with a Growl notifier.

Better yet the tests, coverage and metrics should be run pre-commit and anything less than 100% passing and 100% coverage should not be allowed in the repository.

Continuous Analysis & Integration

Really what we are talking about here is not Continuous Integration anymore, it is Continuous Analysis and Integration. Because it really doesn’t matter if the code integrates unless the code is also DRY and thoroughly tested.

My Wishlist

So here is my wish-list for a CI server to use on upcoming projects:

Integration with GitHub including post commit hooks.
The ability to run tests, coverage and metrics pre-commit via a gem (think like that Heroku magic for deploying).
A project template that includes tabs for artifacts from test results, coverage reports and metrics
Twitter integration.
A growl notifier.
Aware of Ruby/Rails for the collection of artifacts necessary for deployment.
Integrated ability to run capistrano deployment scripts to stage a site if everything passes.
Tasks run as worker process with customizable credentials and not as the Apache user! (I shouldn’t need to mention this one.)
All of this out of the box without hours of configuration.

A Final Word or Two

The idea of convention over configuration is beautiful and should be applied to Continuous Integration.

A lot of systems can do anything but everything is hard. That is just dumb.

Good practices should be simple. Customization should be possible.

Post a comment if you have something that you think fits the bill. I think a lot of people would be really interested in hearing about it.

Continuous Integration with Integrity.

markcm — Wed, 03 Jun 2009 22:30:00 -0400

Nick Quaranto has posted a nice article talking about their Continuous Integration setup over at Thoughtbot.

And while he did a great job of explaining what he did, the details of how exactly he did it were left as an exercise to the reader. Here are the details that you are going to need to actually get this thing running.

There are two parts to this adventure, Integrity and Metric_fu.

Integrity

First we need to get Integrity up and running. Install the following gems first: * Rack (v 0.9.1) sudo gem install rack -v0.9.1 * Sinatra (v 0.9.1) gem install sinatra -v0.9.1 * Thin (v 1.0.0) gem install thin -v 1.0.0

If you are running on OSX then you will need to get require ‘forwardable’ into your environment.rb because it is not there. This is needed for Thin 1.0.0.

Turns out that Sinatra needs to be version 0.9.1 or the notifiers will explode.

The you can then install integrity. Got to the Integrity Website for the details on this. USE THIN. If you don’t you are going to be compiling code as www-data. Create a user account on your server that can access the console and start up thin with this account. Start and stop thin like this:

thin -C thin.yml -R config.ru start
thin -C thin.yml -R config.ru stop

You likely want to have this start with a LaunchDaemon on OSX or something else on Linux. And you likely want to toss this into your Apache config file with a little something like this

############ INTEGRITY PROXY ###########

<VirtualHost *:80>
        ServerName integrity.yourserver.xxx
        ProxyRequests Off
        ProxyPreserveHost On
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>


        <Proxy balancer://mongrelcluster>
                BalancerMember http://127.0.0.1:8910
                BalancerMember http://127.0.0.1:8911
        </Proxy>

        ProxyPass / balancer://mongrelcluster/
        ProxyPassReverse / balancer://mongrelcluster/
        ProxyPreserveHost on

        <Location />
                Order allow,deny
                Allow from all
        </Location>
</VirtualHost>

That should get Integrity going. But, who cares unless it tells that things are breaking. Add a little Twitter notification with by adding the following to your config.ru file:

require "notifier/integrity_twitter"
Integrity::Notifier.register(Integrity::Notifier::IntegrityTwitter)

And then get an integrity-twitter notifier gem installed. I use this one:

git://github.com/hchoroomi/integrity-twitter.git

Great. Now you can get your tests running.

What I’d suggest is to manually check your stuff out and try to have it run on the server. This will help you get all the gems you need for your project installed and let you debug issues.

If things are just refusing to run, ask yourself this question “Who is thin running as and can they run on the shell?”

metric_fu

Nothing worth doing is simple.

Okay with that out of the way we need to get the gem for metric_fu installed and working. First grab qrush’s version: git clone git://github.com/qrush/metric_fu.git

And this is where the fun starts again. Rcov have moved but no one knows yet. So grab it from here: git clone git://github.com/relevance/rcov.git

And then install it by hand:

gem build rcov.gemspec
sudo gem install rcov-0.8.3.4.gem

Before this point you might want to delete the following lines from tasks/metric_fu.rake to stop it from opening the tests once complete:

if MetricFu.report.open_in_browser?
  MetricFu.report.show_in_browser(MetricFu.output_directory)
end

Then you can install the qrush fork of metric_fu:

gem build metric_fu.gemspec 
sudo gem install metric_fu-1.0.3.gem

Bringing it Together

Once this is done you can do something like: rake test:all rake metrics:all

And you should have some tests that run and metrics created. The question remains, how do I get this on the web?

I don’t have the answer to that yet. But I will let you know once I am operational.

Consuming SOAP Services on OSX

markcm — Thu, 30 Apr 2009 09:40:00 -0400

SOAP is bloated and I hate dealing with it. I still have to do it. When dealing with consuming SOAP services from OS X I like to have a couple of items in my bag of tricks to get up and running: a SOAP Client and a way to do base64 decoding. This way I am able to test the service without writing any code. Too often I beat my head against my keyboard over a piece of code only to realize the service itself is the problem.

Here is the SOAP Client that I use: SOAP Client (what an original name!). It really does the trick, though. Point it at the SOAP service WSDL and you are off to the races. It allows you to pass in arguments and call different services. It does it all and returns the XML requested.

Once you have the XML often you will then need to decode a base64 encoded string. Base64 decoding is a bit trickier. Most of the time you can use openssl to decode on a Unix based platform but for some reason it doesn’t seem to work for me. I have had to resort to the following perl script:

#!/bin/sh # decode a Base64 encoded file, as a side effect of # openssl base64 handling (but without encryption) /usr/bin/perl -MMIME::Base64 -e 'print decode_base64(join("", <>))' < "$1" > "$2"

The script takes two arguments: and input file and an output file. I am not a “perl” kinda guy so the script is mostly stolen and probably can be hugely improved.

If your data is a base64 encoded string of gzipped data the next step is to toss the old ".gz" extension on the file and extract the contents using the OS or using gunzip.

Basic stuff really, but it is a pain to track down so I thought I would toss it all in one place.

Prioritize Work (Get Paid)

markcm — Thu, 05 Mar 2009 03:56:00 -0500

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.

Fail (or Succeed) Quickly

markcm — Wed, 04 Mar 2009 08:08:00 -0500

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.

Defining Done

markcm — Sat, 28 Feb 2009 22:30:00 -0500

Ever ask someone how they were doing and then got the reply, “Fine” - what does fine actually mean?

As far as I can tell fine used to mean a little closer to good then bad but now I am convinced that it actually the equivalent of someone saying either “You don’t really care how I am feeling and I don’t really care to tell you!” or it means “I am feeling so bad right now that if I actually tell you I am going to burst into tears and it is going to ruin your day.”

I think that software teams have the same problem with the word “Done” - what does done actually mean?

Done can mean a lot of things including:

Delivered
Documented
Tested on Production
Pushed to Production
Staged
Tagged in the Repository
Acceptance Tested
Ready to Demo
Committed to the Repository
Unit Tested
Peer Reviewed
Ready to Test
Barely Working

What does done mean for your team?

An exercise that like to do is to have everyone write down their definition of done and then read out the definitions to the team (obviously without naming who wrote the definition). Then as a group come up with a universal definition of done. Once you all agree hang it up on the wall in a nice frame. Have the creators sign it. The visibility of the definition will keep people honest.

It is important to note that the definition will need to be different for every team. You probably do not have access to the production environment. Maybe you work for a large company that has policies requiring someone else stage or acceptance test your code. Work with what is realistic.

When it comes to the definition of done the most important thing you can do is just talk about and agree upon the definition. The definition is less important.

Once things are getting done then work on expanding your definition.

When you are starting out it is sometimes a tall order to go from a concept to code that is working on production in a week. There needs to be a lot of tools in place to allow this to happen. As the team gets better include more in the definition. If you are working on a large project going from a Story to Done in a week or two might be a tall order without the right processes and the right tools.

Here are some practices and tools that will help expand your definition of done:

Behavior Driven Development: rSpec, nBehave, NSpecify, JBehave, NSpec
TDD and Unit Testing: xUnit (Yeah, there is a unit test framework for your platform. You need to fine it though.)
Continuous Integration: CruiseControl, CruiseControl.NET, Cruise, TeamCity
Virtualization: VMWare, Cirtrix Xen
Scrum, XP: Mingle

When we started out our definition of done was demo-able. Now it means delivered.

Start small. Think BIG.