HELLO WORLD,
this blog comes from an email exchange with a fellow Tabbles-fan, who asked to help him with development: I’ll call our fan Pavel and say that he comes from Russia 🙂
Pavel has an idea for a product: an Outlook plugin, that would use Tabbles as tagging engine in order to overcome Outlook’s categories limitations. Pavel is planning to commercialize the plugin as a standalone product, sell it as a yearly license on a per-user base, so he’s already allocating (considerable) resources for marketing and sales of his product. Pavel has little experience software development (the experience he has, doesn’t fit well with the case discussed above) and is concerned about the following things:
  1. If he hires a developer to develop his product, he is afraid the developer will run away with his code and start selling his product
  2. He’s not sure on how to evaluate the developer, how to measure the performances and the quality of the work
  3. He’s unsure about how the whole development cycle should be structured and managed
Below are my answer to the points above.

Part 1: how to prevent the developer from running away with my code?

I’d look at the project from a different angle and would anyway recommend to do the following considerations. Let’s consider 2 different cases for a custom-developed software.
1) Case one: the product is targeted to a single specific customer (let’s say “BestVerticalMachines”,  or “BVM”) and based on a detailed request coming from the customer. The software is very specific, and works only with products from BVM.
2) Case two: the product is an entrepreneurial idea and it doesn’t have customers yet, it has a wide target and requires a marketing effort to be commercialized.
In case one, the risk for the developer to do the work, get paid, run-away and sell the code to “BVM”  (or possibly even to BVM’s competitor) may exist… in that case, you want to make sure your contract with both the developer and the customer is written according to your needs. I have heard of situation like this happened, but it was only when the software was targeted to a single customer – and the software was expensive (many thousands of EUR).
In the case two, if the developer wants to run away with the code, he won’t have a single customer to sell it to, but he’ll need to build sales & marketing operations in order to sell the product. This is something that most developers are neither willing nor capable of doing.
Therefore, based on my experience and my good sense, I don’t think that outsourcing your Outlook Plugin is very risky.

Part 2: how to evaluate a developer’s work (outsourced or not!)

When you develop software, for any feature that you need developed, there are infinite ways to develop it. Now, a programmer that can develop that feature (and make it work), with one line of code, is better than one that can make develop it in 5 lines of code, and MUCH better than one that can make it in 50 lines of code. So the answer to your question is: you don’t measure a programmer’s work by how many lines he writes (like you do with a copywriter) but from:
  • if the code works (the most important)
  • how clean, structured and easy to maintain the code is
  • how good is the developer to stick to deadlines
The key for the three points mentioned here, are to have a solid mockup and an accurate specs for it…

Part 3: how to manage an outsourced software development cycle

A good practice when developing software – particularly when outsourcing – is to follow the following steps:
  • First (Design): do a mockup (wireframe)
  • Second (Specs): write detailed specification
  • Third (Development): write the code
1) Design: try and google “mockup wireframe” and “software mockup” or have a look at this http://www.robbinsmart.com/?p=1174
Doing a good mockup is crucial for the success of a software development cycle. I feel that, if you spend 2 days (and 500-1000 USD) doing a mockup with an experience developer, you will immediately feel that, that was a good investment.
The way I recommend you to do it, is to hire a developer (for a day or two) that you can sit together with and explain him your ideas: the problems you are trying to solve and how you are thinking about solving these problems. While doing the mockup, a good developer can immediately tell you “this can not technically work” or “this is a bad idea” or “I think we can do this in a better way”. Sitting down with the developer, face-to-face, is crucial: the process of doing a mockup is a very dynamic one, it needs a lot of communication and it will typically involve one or two extra iterations.
After the first draft of the mockup (you can do it together with the developer in 2-3 hours), you will go home, think some more about the design and write down a couple ideas on how to improve it… The developer will do the same and next day you can meet again and do a second round. The result (a good mockup) will contain a detail description of what each button/feature should do, from the user’s perspective.
2) After the mockup is stable (meaning: you are satisfied with it and you don’t think you need to add or remove anything for the first version of the product), you will give this to a developer (maybe the same one), who will start working on the “specifications”. Writing specs means, that a developer will sit down and figure out what code has to be written “behind” each button and feature or, if you like, what each button/feature should be like, from the developer’s point of view.
3) The Specs. Let’s say that you have 3 buttons:
| New email | Open last email | Search email |
Let’s assume the Outlook plugin will be written using the Office Automation library (the library we use for our plugin). For each button, the developer will need to find out what is the best architecture for the product, that means:
  • What class(es) and method(s) of Office Automation need to be used (from this list:  https://msdn.microsoft.com/en-us/library/bb208225.aspx )
  • What data structure and/or functions need to be used/written
  • If and how a 3rd party API will called (like the Tabbles API for example)
Writing specifications can take some time and the output can be a long document. When outsourcing, this is the most important part of software development cycle. If the specs are good, what follows is “mechanical work”.
If the specifications are accurate and well written, you can give them to any developer: he can look at the specs and will either tell you “I will need 10 hours for the first button, 5 hours for the second and 50 hours for the third” or “I can not do this, look for someone else”.
Once you have that estimate, you can write a contract with the developer for (let’s say) 65 hours, and then go home, make yourself a cup of tea, and wait.
If the mockup was done well AND the specifications were correct AND the developer knows what he’s doing, you can expect him to take about twice as long as planned (but he should know this, so it should be in his/her initially price estimation) and then he should deliver you a first “beta” of the software.
The first beta will have the features requested (technically called “feature freeze”), but you can expect it to crash. Your job here, would be to test all the possible use scenario that you can think of, along with the impossible ones (including just hitting buttons randomly and enter junk value in whatever form or searchbox are built in your product). This process (although you are doing it in a basic and unstructured way) is called “beta-testing”.
Following each round of beta-testing, you should expect a round of bug-fixing: if the code was written well, that should in total take around half of the time estimated for the development (so around 30 hours here).
So, after Mockup + Specs writing +  ((65*2) + (65/2)) hours if you’re lucky, you’ll have your product 🙂
In the next episode, we’ll follow our friend Pavel in his outsourcing adventure, marketing his product and ending up buying Microsoft AND Google 😀 😀