Just For You Software Logo

Custom Software Development

The old method of custom software development, called the “waterfall” method, is where we listen to your requirements, ask 200 questions, note down what you want, go away and design it, build it, test it, document it and deliver it.

Unfortunately the waterfall method has, according to published research data, only a 50% success rate. That’s right, fully half of the software developed in this fashion is never used.

There are many reasons for this but the most important point is probably that there is an imperfect communication between the client and the developer. No matter how good each of them are at communicating and no matter how hard they try to ensure a perfect duplication, it just doesn’t happen.

50% is too low a success rate for us to be comfortable with using it as a methodology for most of the jobs we do.

So if delivery and feedback only after a long development cycle is not the way to go, what is? Short development cycles with frequent feedback. This is the Agile method of development. You can read more about it at the Agile Manifesto site.

The waterfall method does have some strengths. It is good where a very fixed set of requirements is known up front and there is good reason to fix the design, such as when you are rebuilding existing software. This could also be relevant where you are building a system on which people’s lives depend, such as space shuttle software or life support systems.

The Agile Method Explained

It is based on what is call iterative and incremental development, where the project is split into (usually) equal stages (can be 1, 2, 3 or 4 weeks) and some functionality (working software) is delivered each period. We do the following:
Decide in conjunction with you what need to be built this iteration
Design the menu, forms, reports and code
Develop the functionality to be delivered
Debug the working code
Document the functionality to be delivered
Deliver the working software
Duplicate the process for the next iteration (Rinse and Repeat).

Why use The Agile Method?

The Agile method is far more suited to incomplete or changing requirements. You may ask, “Why is that a factor, I know what I want!”

I’m sure you do, in concept. The trouble is, the devil is in the detail. There is a lot of fleshing out to do in software development. A one line concept, “I just want some simple software to get an object to go from a known position, A, to another known position, B”, starts a multi-billion dollar missile guidance software development program.

Now I know you don’t want one of those, but you get my point, there is a lot that can be summarised in one simple statement. In software development, the only time something is ever truly simple is when you close your eyes and conceive an idea. As soon as you open your eyes and start to get your idea to work in the physical universe, that’s when the complexity sets in.

WARNING: With this next statement I might completely turn you off custom software development. If I do, that will be a good thing, becuase you don’t have the drive and persistance to see a software project through to a successful completion. Better you go donate the money to charity than blow it on an unsuccessful software project.

If you have thought through every menu option, every function and every mouse click, have produced a detailed screen design for every form and a sample of every report including layout and search criteria, have a document detailing explicitly every additional feature that could possible be added to improve the program and done a cost\benefit analysis to substantiate why that feature was not included in version one of the software, you will be the first person to contact us who has. Nobody has ever done that for us or even been prepared to pay us to do it for them. Nobody ever threatened to do it or even looked like they might. I feel pretty certain I will go to my grave without that occuring.

One of the reasons is because that process is part of the software developer’s job. Another reason is that most people are far better at improving an existing design than creating a good one from scratch.

What we have found happens in real life is that when we give you the most important functionality first, you start playing with it and can then easily see what changes are vital, important and trivial.

Because you will always run out of money before you run out of ideas it is very important that we deliver the most important functionality to you first.

If you get all of your vitals and most of your desirable features before you spend your budget we will both have done a good job. You will be much happier with the result than if we had charged into building the feature list you had at day one.

Specific Advantages of The Agile Method

In my experience of developing software for small to medium sized businesses, this software development process has several advantages.

Faster ROI

It gives you a rapid return on your investment because you are using some of the software far sooner and longer than would otherwise be the case.

Less Expensive Mistakes

We get to provide you with a fast feedback loop, so you can correct any omissions or misunderstandings that occurred in the communication process.

More Flexibility

You get to work with the core functionality of the new software before we add all the bells and whistles. This enables you to use it and decide if the additional features you thought you wanted will really give you the best return on your investment compared to others you think of while using the software.

Higher Chance of Success

According to the Standish Group, “smaller time frames, with delivery of software components early and often, will increase the success rate.”

Increased Certainty

If a major change happens part way through a large project and you have to divert funds from the software development to a more pressing cause, the money you have spent to date has bought working software delivering core, usable functionality. Being guaranteed working software that satisfies a core need delivers far less potential for a failed project and wasted investment.

If you would like to know more about any aspect of what I have written or how it relates to you or your project, call me on 02 9552 3311.

Tom Grimshaw