Posted on September 25, 2008 in Software Development by Rob Di Marco9 Comments »

Building a successful product is hard.  You think so much about what features a user needs and how you can have a better product than your competition, how you can win.  However, sometimes we forget an important part of the process, how do I make it easy for a customer to buy.

Let’s look at two examples of products that I like, one that makes it hard to buy and one that doesn’t.  First I am going to pick on Atlassian, an Australian-based software company that has built the excellent bug tracking software Jira and the enterprise wiki software Confluence.  I am picking on them because I was just talking with a friend who was having trouble buying from Atlassian and inspired this blog posting.  Now, Atlassian made a very smart marketing decision, they decided to give away their software to open source projects.  This got their products used by a variety of popular open source projects (e.g. JBoss) and in turn got them visibility by both developers and users of these products.  Very smart move, giving away the software got you more exposure to potential customers than any number of Google keyword ad buys.  Well done Atlassian!

So Atlassian has a strategy to get developers aware of the value of their product.  Now think about how buying their products work:

  1. Developer sees how wonderful Jira is while working on an open source project
  2. Developer goes to the Jira product websheet and sees a great presentation of the features of Jira and gets all excited
  3. Developer wants to get his company to use Jira
  4. Developer has no authority to spend money at his company, he needs to talk with his boss
  5. Developer tells their boss "We should use Jira"
  6. Boss says "Why should I buy this? Bugzilla is free!  Do an ROI (Return on Investment) analysis for me and I’ll consider it"
  7. Developer does not know how to do an ROI analysis so he just gives up on Jira and goes off grumbling to his co-workers that the boss "just doesn’t get it"

So what do we see here.  Atlassian has done a great job of getting software developers aware of how wonderful their software is, but they do not help the software developer explain to their boss why they should spend $4,000 on the software.  What they should do is have a simple form that helps a developer  ask questions like "How many people are in your development organization", and "How many hours do your developers spend trying to understand what features are in a release".  From these questions, it should show you how long it will take for the productivity improvements that Jira will bring to equal your investment in it.  Make it easier for our hypothetical developer to create the ROI analysis required by his boss.

Now, the second place that Atlassian fails to make it easy to buy is in their actual purchasing methodology.  If you try to buy from Atlassian, they will only take check/money order/credit card.  They won’t take a PO (purchase order) number.  I don’t know how businesses operate in Australia, but in the US, most businesses that have an accounting department (which are all but the smallest businesses) strongly prefer using purchase orders over credit cards and checks when making capital purchases.  There are various reasons for this but the fact is forcing payment through credit cards or checks is just another hoop that our hypothetical developer has to go through to get Jira installed at their office

The point is that Atlassian has done a great job in getting users aware of their quality product, but they ignore the organizational process by which their customers buy.  I am confident that Atlassian is losing sales not because of their prodcut but because it is such a pain in the ass for a developer to figure out how to justify and how to actually purchase their product.

Now let’s look at a good example of making it easy for a customer to buy, buying music through iTunes.  With iTunes 8, their was an introduction of the "Genius", basically a tool for finding other similar music based on what you are looking at.  Suggestions are shown with the price clearly marked a simple "buy" button right there.  You are staring at the buy button.  If you click on it, it will charge your pre-configured account.  Boom, that’s it.  It reminds me of the candy that sits in the supermarket aisle.  It’s right there, reasonably priced and simple to buy.  No hoops to jump through, very easy to purchase.

 

 

 

The moral of the story, it’s so hard to make a succesful product, don’t handcuff yourself by making it hard to buy.

Thanks to Kevin for inspiring this and Kyle for making me write this.

Edit #1: I used the word "easy" in the moral when I meant "hard"…fixed now.

Edit #2: Fixed some typos and grammar errors.  Also added word for clarity as suggested by Christian

Posted on July 15, 2008 in Software Development by Rob Di Marco5 Comments »

I have been trying to use MapMyRide to track my workouts.  While they say they will have a JSON feed soon, for now, all I could do is work with their RSS feed to put it up on my blog.

Originally, I hoped I could just use a standard WordPress RSS feed widget to show my workouts.  Unfortunately, the feed from MapMyRide contains HTML.  The RSS widget wisely escapes the HTML to avoid XSS.  However, this makes the workout listings look very ugly.

So I have created a pluging that downloads the RSS feed, parses out the workout information, and shows your workouts.

You can download the initial version of the plugin.  Installation just requires you to unzip and put in your wp-content/plugins directory.  Please let me know if you are using it and if there any other features needed.  I know I still need to:

  • Protect agains XSS (split on the bold tags and then escape other HTML
  • Protect against bogus URLs, only MapMyRide.com should be used
  • Add more options to control what you actually allow to display.  Not sure if I want my weight out there.
Posted on May 14, 2008 in Software Development by Rob Di MarcoNo Comments »

About six months ago, I switched my work computer to a MacBook Pro.  Today, I read a LifeHacker tip talking about easily forgotten/not know about Mac features. One that I had never heard of was using the say command, a terminal command that will speak whatever text you send to it.

> say Hello World # Will speak from
> say -f /etc/hosts # Will read out your /etc/hosts file

Hmm….I wonder how my code sounds.  I’ve always been a big fan of the development concept that your code shouldn’t need a ton of comments if it reads well.  But how would it sound…

Turns out some Java code sounded pretty good.  I could definitely visualize and understand the class as it was being read to me.  But some Ruby code I was working on sounded terrible; I chalk it up to the lack of verbosity in the language. 

Another interesting use of the command for me is for README files.  I usually lack the patience to read a whole README file, but I have good retention of those things that I hear.  So when I see a README file, I can now just have say read it aloud to me and I get the content as I dive into whatever I am doing!

 

Posted on April 3, 2008 in Software Development by Rob Di Marco1 Comment »

Started working with git for the first time last week and I am really impressed at how powerful the tool is.  I’ve been interested in using a distributed version control system like git, darcs, or mercurial for a while, but I have been turned off on actually making the move because of the lack of integration with these version control systems and other software (bug tracking, automated build software, etc.).  Also, as a manager, I did not want to have to retrain a whole team of developers on a new version control system.

But enter git-svn which allows me to use git locally and Subversion for the distributed repository.  So now I get the best of both worlds, I can make my local branches and commits, but I don’t have to retrain my team or worry about integration as we still have all of the Subversion interfaces for interacting with the repository.

Using git-svn is pretty simple.  I had to install on CentOS, Max OS X, and Ubuntu and git was available through yum/apt-get/Macports.  To check out was just:

git svn clone http://svn.automattic.com/wordpress/ -ttags -bbranches -Ttrunk

This command will check out all revisions from Subversion and keep a copy of this locally.  Because we download a copy for all revisions, it can take a long time to do this initial setup.

As for the -t/-T/-b, this is used by git-svn to associate SVN branches with git branches.  This configures your git master branch to correspond with the wordpress trunk, but also gives you a git branch for each SVN branch if you want your changes to be tied to a branch rather than the trunk.

One the clone completes, I can use all of the git tools to my heart’s content.  Local checkins, branches, easy merges, etc.  If I need to refresh from Subversion, git will get all new changes from SVN, then replay my edits on top of it.

Committing changes back (assuming that you have permission) just requires:

git svn dcommit

All of your changes are now committed one at a time to the SVN repository.  Very simple for me to get set up and run with.

Digging Deeper…

As I started using git more, I realized how perfect it is for another big problem that I have, managing production configurations.  For example, I have a common problem when managing Apache configurations.  I have the following needs:

  • I use multiple conf files to manage my Apache installation (main httpd.conf, virtual host, SSL, etc.)
  • I want basic version control over the files to track changes over time
  • When trying to debug a problem, I often have to go into the files and tweak multiple debug settings (LogLevel, RewriteLogLevel, etc.).

 What git does for me is lets me do is to create a branch that just contains my debug changes and lets me easily merge the master branch in with these changes.  To do this, I create a debug branch that contains all of my changes needed

git branch debug

git checkout -b debug

..make changes…

git commit

git checkout -b master

… debug is now off…

.. Make changes and commit back to master…

git commit

 ..Now when I need to debug again

git checkout -b debug && git merge master

The merge command will sync the debug branch with the master branch and then will REPLAY the changes that I made to turn on debugging.  When I finish I can turn off my debugging by

git checkout -b master

 I see using this not just to manage logging but in other configuration management problems like:

  • Managing database connection information
  • Configuring network arrangements
Posted on January 26, 2008 in Software Development by Rob Di Marco17 Comments »

I’m on a hot streak tonight… Another comon problem that I have had to solve recently is how to attach a build number to files that are being generated out of an Ant build script.

We have developed a versioning scheme (inspired by http://geekswithblogs.net/emanish/archive/2006/09/25/92219.aspx) for our releases where our release are named <major>.<minor>.<revision>.<build>. So a valid build number might be 1.18.2.1077. This means it belongs to the first major release of the software, the eighteenth minor version, it is the second attempt at a release for this minor version (usually bug fixes), and it is related to the SVN revision number 1077. Any time we are doing a build we are tagging in our Subversion repository to keep the build number tied to the tag. When I build a release, I want my artifacts to look like to look like this: app-1.18.2.1077.ear.

There are a few ways to do this, One way that I considered was to just include a property or Subversion tag in the build.properties file. But I did not want to maintain it and I have always loathed the auto tags that were available in CVS.

My second option was to use the <svn> Ant task. While this will probably work, I have varying degrees of success using the Java SVN library, especially when connecting to Subversion over SSH as we are doing for this application.

So, I decided to go with using the task in conjunction with svn info and svnversion to set the full.build.version property to the current release number. This assumes that the repository checked out is of the format svn://REPO_NAME/tags/<MAJOR>.<MINOR>.<REVISION>

<exec outputproperty="build.current.revision" executable="svnversion">
         <arg line="-n -c" />
         <redirector>
           <outputfilterchain>
             <tokenfilter>
                 <replaceregex pattern="^[0-9]*:?" replace="" flags="g"/>
             </tokenfilter>
          </outputfilterchain>
        </redirector>
</exec>
<exec outputproperty="build.current.version" executable="svn">
  <arg line="info" />
  <redirector>
  <outputfilterchain>
  <linecontainsregexp><regexp pattern="^URL:" /></linecontainsregexp>
   <tokenfilter>
     <replaceregex pattern=".*\/([^\/]+)$" replace="\1" flags="g"/>
   </tokenfilter>
  </outputfilterchain>
</redirector>
</exec>

<property name="full.build.version" value="${build.current.version}.${build.current.revision}" />

I’m sure that I could have gotten the revision from the svn info rather than svnversion, saving a command, but I wasn’t inspired enough to do it. Maybe when I have more time.

« Previous PageNext Page »