Bespoke software: more affordable than you think

Most people are unaware how far the cost of software has dropped in recent years. There still seems to be a perception from the days of mainframes when it would cost a few thousand pounds to generate a new report. We all know how much cheaper it is to create a spreadsheet but the cost of programming has almost dropped as much.

Also, a bespoke application will provide a much better solution and be more efficient. So after a few months a bespoke solution can actually cost less than a spreadsheet.

Why use bespoke software

To be successful, an organisation needs a competitive advantage. It needs to do something differently and better. This will be constrained by off the shelf software. There are many opportunities from creative use of processes and customer interfacing. Organisations do not become great by following everybody else.

Spreadsheets will normally be the best way to provide a one-off solution but they are not convenient. For any application that has to be run regularly they are inefficient. The staff costs in using a spreadsheet will be higher that with tailored apps. In the long term, a bespoke solution will almost always be better value.

Also, while your staff are developing spreadsheets, they aren’t doing their main job.

Why has the cost dropped so much?

There are a number of reasons, including:

  • Modern programming languages like PHP are much more efficient than older languages like Cobol and Basic
  • SQL databases enable data tables to be created and modified in minutes rather than days.
  • Manipulation of data typically only takes a few lines of SQL
  • PCs and development tools
  • Better techniques, object orientation haa slashed debugging times.
  • Programmers’ wages have not kept pace with inflation.

There’s a chilling perspective here. In the 1970s I had to add some fields to a database and change the length of the main key field. It took a team of programmers six months. A similar exercise last year took about 3 hours.

See more tips on deploying software at www.mcmillantech.co.uk/Blog.html and
www.mcmillantech.co.uk/ComputerPrograms.html.

Controlling software costs

Software projects are seriously prone to run over budget. There are a number of reasons why this happens. Some common ones are:

  • lack of clear requirements
  • late changes
  • focus on the desirable rather than the essential
  • uncontrolled implementation

Be clear what you want

When planning a software project, you should know what you want it to do. You should make a list of everything you want the new application to do. You may be clear about this, more often you will talk to the users and find out what they need and would like. As you do this, create two lists of functions and features. One will list every thing the app needs to do, the other will list what people would like it to do.

These lists will form the basis of tender. The more thought you give to the requirements, the easier it will be to control the project. Suppliers will be clear as to what they must provide. If you skimp on this, after the software is ordered, more requirements will emerge. This leads to unplanned extra costs and often wasted work and disputes. The wisdom in the software industry is that every day skipped in the design phase of a software project consumes a week in the later phases.

Avoid Late Changes

Late changes are expensive. They mostly happen because not enough work was done laying out the requirements. Late changes result in wasted work. Work that has been done has to be discarded, other work is duplicated.

Software projects are like construction projects in this – imagine changing the design part way through building.

Focus on the essentials

Another factor is a lack of focus on what is essential and what would be nice to have. The way to overcome this is to break the requirements into mandatory features and desirables. Then, concentrate on implementing the mandatories first. (A main reason why major government I.T. projects fail is because the government fails to do this).

If the budget runs out, discard some of the desirables. If the quotes for the work are too expensive you can also discard some desirables.

Despite what I have said about late changes, most software projects do uncover extra requirements as they progress. Don’t commit the whole budget – allow for extras. Make sure your supplier understands which features are mandatory. A good software company will expect this. Then, make sure he delivers the mandatory features first. Only provide the desirable features when all the mandatory ones are working. You can always add the desirables later.

Control the roll out

It can be difficult to test software. Applications tend to be complex and there can be thousands of routes through an application. Some combinations of data or events can be obscure and the testers will miss them. But the hardest thing to test is the human computer interaction. Computers are predictable, people aren’t. The developers and managers know what should work: other users don’t and they do unexpected things that can break the system. It’s not a bad idea to test the system on the least tech savvy person you can find.

If you have a large number of users, don’t launch new software on all of them at once. Apart from anything else, most support issues occur within a short time, so rolling out the software smooths the support. Dealing with issues from 5 users is a lot easier than from 500.

When I supply packaged apps, I usually find that only around 80% of problems are found during the in-house (alpha) testing. The first few users will find about half the rest of the problems, then successive users each find about half of what remains. Thus, each roll out can be to a larger number of users.

Are spreadsheets and office tools the best way?

Firstly, spreadsheets are a generic tool. They can provide basic reporting but do have major limitations. For example, applications built around spreadsheets are rarely easy to use.

Spreadsheets will normally be the best way to provide a one-off solution but they are not usually convenient to use. For any application that has to be run regularly they are not an efficient solution. They are also very error prone (see below).

The staff costs in using a spreadsheet do need to be balanced against the cost of bespoke software. In the long term, a bespoke solution will almost always be better value. It may cost more initially but the costs will be recovered over time.

Spreadsheets are error prone

A year or so ago, I advised a software company who are spreadsheet experts. It was interesting to say the least. Studies from academics and the European Spreadsheets Risks Interest Group (http://www.eusprig.org/) have found that most spreadsheets contain at least one error. Problems occur when rows are inserted or deleted and formulae are not adjusted properly. How do you check the results of a spreadsheet calculation? One man told me he checks by adding up the column with a calculator. You have to wonder about the point.

And …

Your staff are not IT experts. They will take longer to develop a solution than the professionals will. They often don’t know what can be achieved so won’t come up with the best solutions.

And while staff are developing apps, they are not doing the job they are paid to do.

 

What is Bespoke Software?

What is Bespoke Software?

Bespoke software, often also called custom software, is software written for a specific purpose. Bespoke programs can be written by an in-house programming team, or ordered from a software house. Simple custom programs can be written by the user.

Broadly, there are three ways to achieve computer software:

  • commercially available packages (off the shelf software)

  • bespoke software

  • by configuring spreadsheets and similar tools

The word bespoke was originally a tailoring term and referred to a suit that was made to measure. Comparisons between tailoring and software are apt. The opposite of a bespoke suit is off the peg. In the same way, packaged applications are the alternative to bespoke software.

The cost of bespoke software can vary from a few hundred pounds to over a million. It is often perceived as being expensive. Perhaps this is because users are more aware of the larger systems. However Wikipedia in an article on custom software http://en.wikipedia.org/wiki/Custom_software suggests several reasons why bespoke solutions are not always more expensive than packages. Often, the costs of configuring off the shelf systems can reach those of a bespoke system.

Why use bespoke software?

There are several reasons to use bespoke programs. Typical reasons solution are:

No standard package fits the need

Competitive advantage

There are times when you need to deliver more than your competitors

You are not at the whim of the supplier’s upgrade policy

Packages are updated frequently. This can entail training. Some suppliers (Microsoft is one of the worst offenders) change standards, too. This all increases costs.

Easier to negotiate conditions

Packages tend to be supplied by larger companies with standard conditions. When you order a bespoke solution, you can tailor the conditions as well as the actual programs.

In conclusion, although a bespoke solution will usually cost more than a packaged app, the benefits will be also be greater. Ultimately, a bespoke solution will develop more profit.

Creating Good Apps: Get the Design Right

Planning the Design

Design is one of the most important parts of developing software and one which is too often overlooked. There is a saying that every day skimped on design costs a week in programming. Poorly designed software costs much more to produce, debug and maintain. It is much more prone to bugs.

There is a huge temptation to just start writing a program. This is a serious mistake. You would not undertake building or engineering work without first designing and planning the work. Software should be the same. There will be times when you need to produce something just to see how it will work or what it will look like. This is fine. Treat that like an architect’s sketch pad, or as a prototype. But don’t expect to it this as part of the finished product. Sketch out parts of the program, then continue the design process.

Also, it is much harder to change a finished program than to modify a design document. Late changes consume a lot of time in repeating tests that have already been done. Late features tend to fit badly into the overall structure of the app. The more late features that are introduced, the more the structure is degraded.

List the User Requirements

The first step is to define the broad outline of the app and its major functions. Try to avoid descending into detail at the start – most people do this. It wastes time and, worse, increases the chance of missing important features. It may help to think of the analogy of designing a house. You would start by specifying the number and sizes of rooms and storeys and whether a garage was needed. Only then you would move on to the more detailed design.

Start by building a list of features that are needed. This list should be a core document for the entire project. To begin with, a list is all that is needed. You will no doubt have ideas on the way some of the features will work. If so, record these ideas but do not lose sight of the fact that you need to build a list.

When you have built the list, separate the items into mandatory ones (must have) and desirables. When you come to build the program, make sure the devlopers provide the mandatory features first. If you start to run out of budget (and you will), you can shelve some of the desirability.

You must then design shedules of requirements and functions, objects and data.

Requirements: Sort into Categories

You will now have a list of requirements. From the software viewpoint, it will not be in any sensible order or have any structure. You now must organise the list into a schedule. This is harder than it sounds.

Start by looking for categories. These would cover broad functions and concepts. Example could be messaging, news, people, advertisements or events. In a payroll system, it could be staffing, gross pay, tax, other stoppages and payslip printing. You may find it easier to draw charts and diagrams.

Be prepared to make several attempts at this,. You are unlikely to get it right first time. It is more important to get the design right than finish it quickly, remember that a day saved on design takes a week in programming.

User Operations

List the operations that need to be carried out within each category. The sort of actions could include:

  • create a new entry

  • delete an entry

  • add a note

  • remove or view a note

  • see a list of contacts

  • see contact A’s details

  • see contact A’ s pictures

Objects

Define the objects that are needed in the app. Object is just another word for thing. Anything that is described by a noun could be an object. Examples could be person, employee, order, account, stock part, document, picture, appointment or widget. Objects are organised in classes.

One way to identify objects is to look at all the nouns in the list of requirements. From this, you can make a list of candidate classes. Review this and decide what classes to use in the app. Then, for each class, list what processes – methods– are needed. Aim to map all the user requirements to classes.

Data Requirements

Make a list of the data needed by each object. Also, for each user operation, record what data is needed. What will the user want to see? In a list of contacts, he may want to see a set of thumbnail pictures., or he may just want to list the contacts. Will the contact’s name be enough in a list? Or will he also need to see the contact’s company?

Check for data the app will need itself, such as logon code, password and email address. You may want to collect statistics, to record how often a user logs on, to record what he views. If this is so, consider what data you will need to collect and record. You may find you need a class for the app itself.

Then design the database tables. Often you will need a table for each class. Look into the relations between the data fields in the various tables. Record which classes need to access data from other tables,. From this, design the key fields for the tables.

Finally

Once you have carried out all these steps, you will have a usable design for the project. The overall cost will be much less, delivery will be sooner and the project will run more smoothly.

This is only a brief summary. There are more details in my Kindle book: “How to Write Software for Sale”, available in Kindle format from Amazon for 99p (UK) or $1.43 (rest of the world).  See details;   Buy: Amazon UK or Amazon.com

Was this helpful? Please like and share the page, or leave a comment.

Have you an idea for an app? See how I could help you.

Do you have any questions? Contact me.

John McMillan

I want to write an app: Where do I start?

Computing Platform

The first decision is which platform you will use to run your app.  The principal modern platforms are PC, Apple Mac and mobile devices (phones and pads).  Some applications are delivered as web services and there are also games consoles.  Think about who will use your app and the devices they will want to use.  Web based apps have the advantage that they can be used on all devices.

Both Apple and Android provide software development kits that provide many facilities that relieve the programmer of much of the work.  These are available as free downloads.

What sort of user?

Do not forget that different people have very different attitudes to technology. Some people love playing with games consoles and smart phones. Some always want fashionable devices. At the other extreme, many people dislike anything technical and just want to do a job. Make sure you cater for what your customers want.

Your mother’s friends have smart phones now!

What sort of app?

There are lots of different types of app.  For example:

  • business
  • games
  • education and training
  • widgets

Their users have different needs and expectations. You need to tailor the way your app looks and works for them.

How to write the app?

If you are writing for a mobile device (phone or pad), you need the development kit for the device.  For Apple, that is Cocoa, for Android it is Eclipse.  If you are writing for a PC, the main choices are Visual Basic (VB) or Visual C.  The main ways to develop web apps are PHP or Microsoft ASP.  PHP is probably easier to use, it is open source and available as a free download.

This post is taken from “How to Write Software for Sale” – available in Kindle format from Amazon for 99p (UK) or $1.43 (rest of the world):

Details Buy: Amazon UK or Amazon.com

Was this helpful? Please like and share the page, or leave a comment.

Have you an idea for an app? See how I could help you.

Do you have any questions? Contact me.

John McMillan

John writes and talks on technology and advises companies on developing and marketing software products. He is the author of Kindle books How to write software for sale and How to market yout business. He has 30 years’ experience in the IT industry and has enabled several bodies to sell their knowledge through computer applications. He has been employed as a consultant by public bodies and by universities.

Have Companies Become too Reluctant to use Bespoke Software?

I was recently chatting to Colm Coyle of RoIT about bespoke software and the way in which few companies now use bespoke software. I made the point that companies largely stopped commissioning bespoke software after the year 2000. We came to the conclusion that it is time they restarted.

The year 2000 forced many computer departments to do what they should have done years before – ditch their mainframes and install networks of PCs. Suddenly, when staff needed new reports, instead of having to incur weeks of Cobol programming, they could create a simple solution on a spread sheet. This has transformed the use of IT but has the process now gone too far? Colm and I think it has.

Competitive advantage

Firstly, spreadsheets are a generic tool. They can provide basic reporting but do have major limitations. Applications built around spreadsheets are rarely easy to use.

To be successful, an organisation needs a competitive advantage. It needs to do something differently and better. This will be constrained by off the shelf software. There are many opportunities from creative use of processes and customer interfacing. Organisations do not become great by following everybody else.

Spreadsheets will normally be the best way to provide a one-off solution but they are not convenient. They are also very error prone (see below). However, for any application that has to be run regularly they are inefficient. The staff costs in using a spreadsheet do need to be balanced against the cost of bespoke software. In the long term, a bespoke solution will almost always be better value.

Spreadsheets are error prone

A year or so ago, I advised a software company who are spreadsheet experts. It was interesting to say the least. Studies from academics and the European Spreadsheets Risks Interest Group (http://www.eusprig.org/) have found that most spreadsheets contain at least one error. Problems occur when rows are inserted or deleted and formulae are not adjusted properly. How do you check the results of a spreadsheet calculation? One man told me he checks by adding up the column with a calculator. You have to wonder about the point.

It’s become economic

One thing that emerged in the run up to the year 2000 was that software had a much longer life than was realised – we discovered that an awful lot of software had its origins in the 1970s. The world of IT has changed out of recognition since then. Development costs have plummeted but I don’t think some IT managers have understood this.

In the 1970s I had to add some fields to a database and change the length of the main key field. It took a team of programmers six months. A similar exercise last year took about 3 hours. In trying to remember why, I realise we didn’t even have databases in those days, never mind SQL. A simple extraction and sort of data required a program. Today it’s one line of SQL. Files were essentially flat, so the length and position of each field had to be specified. Incredibly, programmers rarely employed reusable code. Object orientation did not exist.

Legacy systems often had their origins in this environment which is why, even in 1999, it would cost thousands just to generate a report.

These are not the only reasons why development is cheaper. Modern programmers use integrated design environments (IDEs) which speed up the development process. Object orientated techniques have slashed debugging times. And programmers’ wages have not kept pace with inflation.

Software that does exactly what a user wants is now affordable. In fact, I’m sure it can often be provided with less effort that a spreadsheet solution.