Who owns the software you’ve paid for?

Ownership

There can be pitfalls in ordering bespoke software. One is control of the source code of your application. This can be complex. The biggest issue is ongoing support, but there are three issues:

Definition

Some software is written in compiled languages, like C++. The programmer writes what is called source code in, say, the C language. This is then compiled into an executable (exe) file. There are other languages. For example, most web applications are written in languages like PHP and Java Script. In these cases the source code is deployed unchanged. In such cases, you should be able to access the source code from your web server. However, some web sites are generated by software like Adobe. You may find in these cases that you do not have access to the source code and the site can only be changed by the holder of the source code.

Support and maintenance

This often causes major problems. You commission some software, install it, sign it off and pay for it. You then find the software house charges high fees for any extra work on the application. Many software houses adopt this approach. Others consider it to be unethical.

The worst problems occur after disagreements. If you fall out with the supplier, and this happens far too often, you will be stuck. You may have to order new software. Even taking data from the old software can be difficult.

To overcome this, the contract should clearly state that the software company must make the source code available to you, or at least to a third party. It must also state that the source code must be handed to the client at the end of contract.

Copyright

This will only normally arise if you or the software company decides to sell your application as a package. The legal issues are complex, but, in the absence of a clear agreement, it is quite likely that the software house would own the copyright of the source code.

If there is any possibility that you would want to market the software, this should be discussed before the contract is signed. In fact, many software houses (including McMillan) would be very happy to collaborate with you in marketing a package. This needs to be made clear at the outset.

But what about the software house using parts of the code in other contracts? In reality it will be difficult to stop this, and in any case you would be unlikely to be able to profit if that did happen. It does help to check before agreeing to the order.

Escrow

Software houses do sometimes go out of business. If this happens and you don’t have access to the source code, you will be in trouble. Escrow agreements are common, and state that an up to date copy of the source code must be deposited with a third party.

Some care needs to be taken in drafting the terms of the escrow agreement. By default, the source would probably only be released following the commercial failure of the supplier. The author’s view is that it should be released at the end of contract.

Summary: useful contract clauses

Apart from normal terms and conditions, the contract should:

  • Define the copyright
  • State that at the end of a maintenance agreement, you will have full access to the source code.
  • If the supplier is not prepared to deliver the source code to you, insist that an escrow copy is deposited with a third party. Also insist that you have the right to access this at the end of a maintenance agreement.

Problems are more likely to occur with larger software houses. Smaller ones need to be more flexible and they will need you as much as you need them. So negotiation will be simpler and you won’t need anything like as much access to lawyers.

About the author

John McMillan is a software developer based on the Essex Suffolk border in England, close to Cambridge and North East London. He writes business programs to order, his applications have carried out many business functions.

Have you a need for software?

Visit McMillan’s web site
Contact McMillan to see if we can help

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.

 

Using Web Technology to Provide Low Cost Business Software

Spreadsheets have transformed business. But there are limitations in what spreadsheets can provide. Once the limits of spreadsheets are reached, database solutions are needed. (See my blog What is a Database) . Most business applications, whether bespoke or off-the-shelf, are based around some form of database.

Recently, some software developers have found that web technology can be used to make bespoke database applications much more affordable and usable.

Windows has many advantages and is nearly universal on PCs but it suffers from poor database support. In fact, Windows is really designed for applications like word processors and spreadsheets. There have never really been any standards for providing Windows database apps. The solutions that exist have tended to veer between the very expensive and inelegant. The solutions are rarely easy to set up and they often place many restrictions on the layouts of forms. The lower priced ones are difficult and expensive to maintain.

However, the software to create web sites has become very standard and sophisticated. The software components work well, and many are open source with minimal or no licence charges. Some developers have realised that it is now easy to build business apps around intranets. These reside on the user’s server and are accessed through the browser.

Using intranets to provide apps provides many benefits.

No deployment costs

You only pay for the development, not licences for a database engine

Ease of deployment

Traditionally, database drivers have had to be installed on every workstation. All that is needed to use the software from a new PC is to type the app’s address into the browser.

And, of course, everybody knows how to use a browser.

Wide availability of resources (skills)

Web software, especially the PHP programming language and the MySQL database engine are popular with developers and there are large numbers of developers available. This reduces being tied to one supplier.

Future proof

Web technology is here to stay. The environment is stable and suppliers are committed to the future. Standards are not controlled by users, not companies.

Low cost

Cost of development can be significantly cheaper than traditional methods.

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

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.