The objectives of a scientific software project

Photo by superfem

The starting point for any software project is to know what you're actually trying to achieve.  This post is going to look at how to go about collecting the objectives of a project.



The objective (or objectives) of a project are what you are trying to achieve by completing said project. They should not be confused with anything as specific as code or documentation: those are the deliverables of the project, not its objectives. The objective/s are independent of the methods or approaches you will end up using; those will be decided later on.  They aren’t statements about the how the solution is to be reached (i.e. "write a program to calculate a Bayes classifier from the data") but rather what the solution should do ("predict whether a new patient will suffer from this disease".).  The objectives don't say anything about the way in which they will be met, the algorithms to be used or even the language in which the program will be written.

The reason for this is that you don't want to restrict yourself.  The most important thing is to solve the problem, so you want to make sure you understand clearly what the problem is.  Until you've done that, you don't want to start closing off possible solutions by making specific decisions.  It's very important that you get the objectives clear in your mind (and written down on paper) before you go any further because they are the foundation on which everything else will be built.  If you don't have a clear idea of what you wish to achieve, it will be a lot harder to achieve it!

Stating the objectives

The objectives should be statements, preferably short, that encapsulate part, or all, of what you are trying to achieve with the project.  They should be as concise and clearly stated as you can make them.  Use the shortest words and the simplest language that you can.  Then print them out and stick them somewhere visible.  It is worth having the objectives somewhere prominent so that you can easily check whether what you are doing fits with the objectives.

For example, you might be building a machine learning tool to build predictive medical models.  Your objectives could be:

1 - predict whether a new patient will suffer from disease A
2 - identify which feature variables in the data are most important in making these predictions

Another example might be that you're building an automated software system for detecting stars and galaxies in astronomical data.  Your objectives here could be:

1 - find the sky locations where there is likely to be a star or galaxy, given the data
2 - estimate the flux (brightness) of each source
3 - use the data to decide whether the source is a star or a galaxy

It is worth spending time getting your objectives clear because if they are wrong or incomplete, then the impact will be enormous. A clear set of objectives will help you solve problems that occur later in the development process because it will allow you to check whether the problem, or its solution, fits with the objective. If it doesn’t then you are going down the wrong path. Clear objectives will save you time and the product of your efforts will be much better because it is focused. This clarity of purpose will be found in the very substance of the software you finally write. Software that has fuzzy or contradictory objectives is often messy and unstructured because of the conflicting priorities or targets of the programmer. On the other hand, software with clear objectives is often a pleasure to read because the people writing the code understand what they're aiming to achieve.

Making your objectives clear from the beginning also helps reduces the chance they will need to be changed during the project because you will already have thought them through thoroughly.  Even if the objectives do need to change, which does happen from time to time as you start to implement your solution, clear objectives will allow you to spot this necessity rapidly and act before you go too far down the wrong path.

When an objective must change, you should do two things. Firstly, don’t worry about it. Secondly, stop as soon as you realise the objectives have changed and work out the implications of the change. The objectives are more likely to change towards the beginning of the project as you work out the requirements and design (we'll come to this later; one step at a time!) and when you begin implementing the solution.

In conclusion, clear objectives are the basis of writing successful software. They are the compass by which the project is steered and, if we can continue the nautical analogy, will help you navigate the difficult waters of development.