Development Issues Delay Launch

I hate to say it but we missed our first launch deadline and won’t be launching for a couple more weeks.

The issue has been development but – as much as I would like to – I can’t place 100% blame on the developers.

Grouvia has a lot of bugs and I refuse to launch a sub-part product. I know I only get one chance with my target audience and the level of quality I want just isn’t there yet.

Grouvia has a lot of bugs and the developers haven’t been able to fix them.  They’ll say it’s fixed, we retest… and it’s not fixed.  Worse, we retest these elusive bug fixes and we find more bugs.

Granted, the vast majority of the bugs are minor.  The major bugs have been fixed, or fixed to the point where the remaining issue is tolerable enough to be downgraded.

But there are still too many bugs for us to launch.

I’ve concluded that the best explanation for the development problems are communications issues compounded by language.  I do believe these developers have the experience and skills to do the work.  However, many things point to communication issues as the main reason we are having the problems we’re having…

  • Often the implementation of a particular feature does not meet the requirements.  Actually it’s not often, it’s usually.
  • Details are missed.  A feature will be implemented but the nuances and logic details aren’t there.  For example, the private events were implemented without any way to invite participants.  It was in the requirements, but they didn’t put it in.  Details are not just nice-to-have.
  • The developers make assumptions instead of asking questions.  If they don’t fully understand something, they will make their own decision about how something should work, instead of asking for clarification.
  • The technology is driving the features.  If the developer finds that the technology does not support the feature properly, he will change the feature to match the technology.  For example, the messaging feature was changed to match the abilities of the standard Drupal messaging module. This isn’t what we wanted.

I know that many developers work like this.  I have been in this field long enough to have seen this before, lots of times.  But I’ve always been in a corporate environment where I can call a 2-day-long meeting in a conference room somewhere with American-English speaking developers, analysts, testers, and team leaders and hash out the details.

I don’t have that luxury now.  These developers are halfway across the world and our meetings take place over an unreliable Skype connection at 7:00 in the morning.  We have a daily 2-hour window to work together, sometimes a little more if they agree to work late or if I can get up earlier.

But I’m also paying about a third (maybe less?) of what I would have paid for an American company to do the project.  You get what you pay for.  I knew that going in.

Delaying the Beta launch was disappointing but it was the right thing to do and I know we will have a better product because of the delay. I’ll keep you posted.

* * *

Do you enjoy reading these posts? Why not sign-up to receive Grouvia’s e-newsletter? You’ll get the latest news delivered to your inbox and you can participate in the Grouvia development process. It’s free. Sign up at www.grouvia.com.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: