does anyone know anything about software development

Rob,

Have you tried visiting the MasterMind Groups in this forum? There are some groups in there, which are into software development.

I have software that I had developed for me. I just outsourced the job.

You can also search some ebooks from Amazon for the software development course of your choice.

Honestly... it's a lot harder than you think. There's a reason most people go to college for it, you know? it isn't something you'll learn and pick up in a few weeks.

If you think the software will be worth it (and I assume valuable?) then outsource it.

But as far as "how to outsource it" goes... write down (or type) exactly what you want it to do, how you want it to look, and even try to imagine the variables that will go into it.
- As in "ok when this does this, then the program also needs to do that"

Then visit a site like oDesk and post the job. You don't have to give away too many details but to get a fair and accurate quote you may want to reveal some of it.

Something else to note, it probably isn't going to come cheap. Even if you outsource it to someone overseas, you're wanting a program written from the ground up, you know? And it probably won't be ready in a day or two. You're looking at weeks or even months for development, troubleshooting, adjusting, and so on.

On oDesk:::
Fixed Rate has it's advantages and disadvantages. If there's a dispute, there's no real mediation. But a fixed-price rate will potentially save you money. But you can't track them, see what they're doing, and so forth.

Hourly rate can potentially cost you more money (but it could save, too honestly) but it will allow you to track their work.. nearly in real time. Require them to install and use the oDesk Team software if you pick this option and refuse Manual Time inputs. If they don't track it, they dont get paid.

Robert X, I really recommend using vWorker (RentACoder) for this since it offers a wizard that will walk you through creating a proper spec. This wizard not only offers the "hand holding" you want, it makes sure you provide the details that programmers need to fully understand what you want. You also have access to a money back guarantee and free arbitration (just in case - rarely needed - but just in case).

Your best bet would be checking freelancing sites like oDesk and Freelancer or even the Warriors for Hire section. You don't need to buy a WSO to get this kind of information...

Hi Robert,

This is definitely a question right up my street. I have a masters degree in computer science and have been involved in all areas of software companies for over a decade now. Including development, operations, management and now owning my own company.

The most important thing to get a handle on is the result you want. Most people get hung up on specifics and lose sight of what they really want. So start by writing down the result your app needs to produce. Forget how it produces it (although you can't ignore that, more in a mo). So using my own company DigiResults as an example.

DigiResults will allow affiliates to promote products on the marketplace for a commission paid to them instantly at time of sale.

The next thing to get written down is any technology enablers that will form part of the project. (In your case, it's unlikely there will be any as these tend to be part of a project run by a technical guy). Again, in the case of DR -

DigiResults will use the PayPal adaptive payments API to make these payments possible.

Now you can start to dig into the details. Start by identifying the actors that will play a role in your system. This is any class of person and could include different user types, different tiers of user, different marketing channels. Again, for DR -

Vendor - Someone who owns a product and is looking to get promotions run by affiliates to sell more copies.
Affiliate - Someone with marketing reach looking for products to promote.
User - Anyone with an account on the system regardless of whether they are a vendor or affiliate (or both!).

Once you've identified the actors you can start to write your user stories. Again, focus on what you want these people to be able to achieve, rather than how they will do it.

A good user story is written in this format -

As an ACTOR
I can DO SOMETHING
so that I get BENEFIT

The ACTOR is the person you identified in the previous step.
The DO SOMETHING is what you want them to be able to do.
The BENEFIT is why they'd want to be able to do it.

So let's do some examples from DR

As a USER
I can register for an account
So that I can store data on the system

As a USER
I can sign into my account
So that I can get at my stored data

As a VENDOR
I can list a product on the network
So I can attract affiliates to promote it

As an AFFILIATE
I can promote a product on the network
So I can make money from my marketing reach

Once you're armed with your list of user stories your next job is to prioritise them. Put them in a list from top to bottom so that any item higher up is more important to you than an item below it.

You're now ready to define your MFU (Minimal functional unit). This is the set of functionality you absolutely cannot do without. Start reading down from the top of your list and as soon as you get to a feature that you can do without, draw a line above it.

Everything above that line is your MFU. That is the functionality that must be complete before you can do anything with it. That doesn't mean you are never getting the rest of it, it just serves to focus the dev team (who will be working from the top down) and provides a perfect first milestone. This avoids things such as getting the ability to list products before people can even sign up for an account.

Congratulations. You've now done everything you absolutely need to in order to start contacting developers and get quotes on getting it built. But you can save yourself a lot of time, money and stress by doing more yourself (if you want/need to).

Any good developer will be capable of turning user stories into a working app but the less definition you put on those user stories the harder you make it for the developer (or conversely the worse the app will be if you give it to a developer that can't do the higher level work).

So your next job is to define the user experience. Fortunately, you don't need any great design or development skills to do a passable job of this and, once it's done, your project will be much better defined, easier to develop and thus cost you a lot less.

Take each of your user stories in turn (starting at the top!) and start to sketch the screens that will be needed to produce the result. Things to think about -

- Where is the start of the story?
- What order will the screens appear in?
- What details need to be captured at each stage?
- What details need to be displayed at each stage?
- Where does the actor end up when he's done?

Once you've put some time into defining the user experience for each story you should have a reasonable idea of how the app will fit together. Which means you're now ready to start combining them into a complete site/app. So instead of individual story flows you now have a list of screens connected by a bunch of menus that give access to the various stories.

So to recap, at this point you have -

- An overall results statement outlining what result your app is aiming to achieve.
- A list of technical enablers (likely to be a step most people can miss out).
- A list of actors that will be interacting with the system.
- A list of user stories outlining what the actors want to do with the system and why.
- A list of user experience flows outlining how actors will interact with the system.
- A set of sketches showing how those user experience flows connect together.

Final things to consider -

Developers aren't designers. If you want your app to look pretty rather than just functional make sure the agency you use has designers available or you're going to need to find someone else to do design (could be you of course).

Stuff is going to change along the way. Even by the time your app reaches MFU stage you're likely to have stuff you feel you absolutely can't do without. Fight that urge! If you would've been happy going with it a couple of months ago, go with it now. Get something out there then iterate. You absolutely won't get it right first time and the best people to tell you what to do better are real customers.

In conclusion

There's a ton more to writing a good spec but any more detail would be targeted at people with some experience of creating software so is outside the scope of this post. I hope this goes some way to making your life easier and making your outsourcing run smoother.

If you follow all the steps in this post you'll produce a spec 10x better than 90% of the other projects listed on those sites which means agencies will bid more attractively to win your work and you'll have less surprises down the road.

Cheers,

Andy