View RSS Feed

Caffeine and Donuts

The Argument for Custom Software Development

Rate this Entry
I'd like to start this post off with a couple of questions.

1.) Have you changed background image on your computer from the default?
2.) Have you ever rearranged the icons on your iPhone/Blackberry/Android?
3.) Have you ever bought any seemingly weird gadgets because you had a specific purpose for them?
4.) Have you ever set up a macro in Excel?
5.) Is your desk arranged in a specific manner?
6.) Have you ever bought a car and a.) ticked something on the options list (for old guys who buy new cars) or b.) stuck a huge sound system in the back (for young guys who buy old cars)?

If you answered yes to any of the above questions, I'm sure you'll agree with me that we humans love customization. We know what we want, and if we don't get it, we're not quite as happy as we could be. Since we love to customize everything around us, why should our views on software be any different? After all, many of us use computers each and every day.

When the need arises, you can either have an existing piece of software modified to suit your needs (if the supplier is willing to do so), or if nothing is available, you could consider having something developed from scratch. This post is going to focus on having something developed from scratch.

Let's look at some of the reasons for having a custom piece of software developed;
  • You have a business need that cannot be satisfied by existing software - it could be something simple to give you an edge over your competitors.
  • Existing software is too expensive. Of course, this is relative; no-one is going to develop a SAP-like system for a few hundred bucks, but I've heard of instances where an entire industry is monopolized by one of two companies who charge exorbitant amounts for what is essentially simple software.
  • An application can support one of your products. Perhaps you have a product that can benefit from a 'companion' program. This is the case with one of our customers; they've built a piece of hardware which is supported by a piece of software which we have developed.


Once you've decided that you want to have a program developed, you'll have to find someone who can write it for you. There are a couple of places where you can find freelance developers;
  • Use a freelancing website like www.elance.com. Elance allows you to post jobs and developers can then bid on these jobs. Elance ensures that the customer gets their software and that developer gets their reward. As an added bonus, Elance allows you to view a history of a developer's work as well as their results on various skill tests.
  • Students. For small applications, it is likely that you'll be able to find a bright young student who willl appreciate the extra income. Talk to your friends and family - someone is bound to know an IT student. One of the major advantages of hiring a student is cost; they'll charge much less than an established software house. No overheads = cost savings. With regards to pricing, I'd say that you can expect to pay anything from around R150 p/h (for a student) up to R700+ p/h (for a software house).


Lastly, there are a couple of things to keep in mind if you do decide to have software developed.

Do's
  • Make sure you find a programmer who knows what they're doing. Check a history of their work. My advice to programmers would be to develop a useful application and distribute it for free. I've personally done this, and it helps one to get your foot in the door.
  • Keep in contact throughout the process; the last thing you want is for your requirements to get lost in translation.
  • Set everything out beforehand. Scope-creep can make things spiral out of control very quickly.
  • Make sure you have everything that you'll need when the software goes operational (hardware, other software, etc.)
  • Involve the people who will be using the software. Managers might think that they now how something should be done, but generally, the guy on the floor who's actually doing the work knows more about the little details.


Dont's
  • Don't part with any money before you've seen results. This is not to say that you should pay only when everything is done. Identify milestones beforehand and pay your developer as he/she reaches these milestones.
  • Don't expect a freelancer to move the earth. If you want an invoicing system, ask a freelancer. If you want a full-blown manufacturing/financial/HR system, look at the available options, unless you can afford to wait a year or two or employ a whole team of freelancers.


Do you have any experience with custom-developed software? Please tell us about it.

Submit "The Argument for Custom Software Development" to Digg Submit "The Argument for Custom Software Development" to del.icio.us Submit "The Argument for Custom Software Development" to StumbleUpon Submit "The Argument for Custom Software Development" to Google Submit "The Argument for Custom Software Development" to muti Submit "The Argument for Custom Software Development" to Laaikit Submit "The Argument for Custom Software Development" to My Yahoo!

Updated 18-Sep-11 at 07:32 PM by rfnel

Categories
Uncategorized

Comments

  1. mother's Avatar
    Thanks Riaan, this is very informative. Especially nice to learn about elance. I think the major obstacle is perhaps the enormous information void between programmers and the "regular" folk. :b

    I've often heard programmers complain about scope-creep, and I don't believe it is the customer's intention for this to happen, but rather the result of the customer not understanding how even the smallest request may change the work that has already been done.
  2. rfnel's Avatar
    Mother, you hit the nail on the head. Programmers and regular folk speak different languages, and that makes it difficult to get everyone on the same page. It's very easy for us to go into a lot of technical detail even when answering simple questions.

    I'm sure that no-one intends to make our lives difficult, but seemingly simple changes to core functions in an information system can easily have a wide-spread effect which isn't always obvious to users. If you compare a system to a car engine; a customer can look under the bonnet and say "move that bolt two centimeters to the left". A seemingly simple instruction, especially if you don't realise that moving the bolt could mean that there won't be enough space for the radiator anymore, so you'll either have to invent a smaller radiator or increase the length of the entire car, which means that the electrical wiring will have to be redesigned and the whole car will be heavier, so you'll need to shed some weight elsewhere, which could involve replacing a couple of steel items with plastic, which could mean that you'll have to redo crash tests, etc, etc. Sure I'm exaggerating a bit, but the ripple effect is no joke.

    Where scope-creep also comes into play is when a customer sees an early iteration of the application and they start making suggestions for more features. Once you have an actual working piece of software in front of you, it's much easier to visualize new features (compared to when you have only a specification). This is why I highly recommend that everything be agreed upon beforehand; otherwise a programmer can end up doing a lot of extra work for free.