Skip navigation

Paradigm PoP

Friendly software tools for small and medium sized companies

4 Very Important Things to Note When Getting Software Programmed By Someone Else

A year ago we had some of our code written by someone else.  That year we learned a LOT about getting code done from an outside source.  Now it is a year later, and the site has been in public beta for a few weeks (check it out at  Customers that are using it cannot tell us enough about how amazing a tool we have made (and we are disposed to agree).  That the venture of offshoring my development was more rocky than I anticipated is true.  However, not all is anticlimactic and there are some strong positives I have gained.  That I learned a decade worth of lessons in only a year is also true.  That I am more prepared and more aware in the case that I send something else off shore, this is also true.

I have learned a lot and enough that when I relate my experience to friends and colleagues I have been asked on more than one occasion to publish my advices to the benefit of all independent developers.  When considering what learnings merit publication, I have found that four themes prevail.  Actually I have found that most independent developers should code the first version of the product themselves, get the customers to start buying the product, and then use that money to fund their own ODC initiative.  Still, there are those who would be lured by hiring a team to handle the technicals so they may be left to the business end, and that is cheapest done via an ODC.  To those in both groups, when starting your journey into securing an ODC, remember the four advices that follow. The development team must be superstars and nothing less, the process of development must be very simple, the development environment must be very simple, and the product requirements must be ridiculously simple

Superstars Only

When I began work with my selected ODC, I encountered problems with absentee senior developers.  Naively I lowered my expectations and settled for reliable but weak developers.  These developers would serve a large company well.  However startups like mine flourish by assigning heavy responsibility to all team members.  This works very well when the team is a set of superstars.  As my team grew, I kept the initial developers on because I incorrectly believed that the speed we were moving forward with was expected of a new team.  Then I hired my first superstar.  Once she was ramped onto the team, I noticed a significant improvement in the team's performance.  A few months later, I found my next superstar and again I noticed a jump in performance as he joined the team.  Through all of this, I had still kept the initial two on purely based on emotion.  However, I was intensely aware that the performance was still nowhere near what a four person team should show, and recently I let the last of them off of my team.  Then, almost a year later, I found my third superstar and the performance began to reach my initial expectation.  My lesson in this shuffle is to only accept superstars to your teamDo not settle for less, because you will get much less than you settled for.

No Complicated Process

Initially I felt that the development must be measurable via a process.  I taught the team Scrum (the picture at summarizes Scrum nicely) and we swore by it because it gave us the feeling of forward momentum (with the burndown charts, and with working through yellow stickies every week).  However, there were two problems with Scrum as we had implemented it.  First, we had only the illusion of speed when in fact it still took us a few weeks to get basic CRUD (Create, Read, Update, and Delete) operations working on our most basic of objects.  Second, when I returned to the US the team followed only certain parts of Scrum making the sum of it ineffective as a measurable process.  They would not be regular about stand up meetings and the tasks they would choose would not be easily measurable (tasks chosen ranged from the vague "fix issues" to the all encompassing "write all user code").  There was too much overhead and not enough return so Scrum was dropped.  Still, I needed something to tell me how fast we were going and so I introduced a simple process.  We now report all features and issues to our issue tracker.  Developers are assigned issues from that list and as they finish each issue, the issue is marked resolved.  Here it comes back to me where I can confirm the issue is indeed completed and I close it on the same issue tracker.  In this manner we measure how many issues are getting finished, who is performing well, and where our wheels tend to spin.  It is simple, it is straightforward, and it works.

No Complicated Environment

During my first month of development I had to teach my team how they should use the wiki to store documents, use the issue tracker to store issues, and use subversion to version control the code.  Of these three, the wiki was a waste because in an agile environment there should be no documentation.  Yet we continued to use all three even to the point where I moved the hosting to a computer in the ODC company's intranet for faster access.  Four months ago, that computer lost its data.  There were no backups, and although we had the code on our local machines, the wiki and the issue tracker were gone.  Here was my opportunity to start over with less clutter.  I contracted a server from Linode ( which has great hosting for people who know how to administer servers.  On this server I created a minimal setup with an issue tracker and with version control software and then I backed it up to Amazon's cloud.  Now the team must only learn two tools and maintain two logins, and I will probably never have to feel the pain of wiped data again.

Half Your Product

...and then half it again.  Initially I had envisioned a large set of requirements for my project management website (large in comparison to what I have now).  I had reduced the set to what I thought was a minimum critical mass required to attract business.  As we encountered difficulty and as deadlines were missed, I cut those requirements in half.  Twice.  Then we had a set of features that was digestible by a fresh ODC team.  Today we have a tool that is small and amazes everyone who uses it.  Additionally we have an audience that we can excite as we introduce the features we had to push to the back burners earlier.  Not to mention the great value to understanding a product by pulling out fluff and reexamining the core.  I attribute a great deal of the strength of my product today to this process it underwent five months ago.  A product is always envisioned much bigger than it needs to be.  How much bigger?  Four times bigger.

Much delayed my ODC effort.  The complexity that was allowed in at different points and a lowered set of expectations at the start were major factors in this delay.  However, I find myself today with a stellar product and a growing customer base.  The next opportunity that comes along for us to contract an ODC I will be better equipped with these four guidelines at my side.

Post new comment
The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options