Development Complexity & Price

Difficulty

It is difficult to calculate how difficult an app will be to build, but it can be useful to know this when developing a quote for an app. There are a few different approaches that you can take.

You could use Halstead complexity measures which are software metrics introduced by Maurice Howard Halstead in 1977 as part of his treatise on establishing an empirical science of software development. Halstead made the observation that metrics of the software should reflect the implementation or expression of algorithms in different languages, but be independent of their execution on a specific platform. These metrics are therefore computed statically from the code using the following:

For a given problem, Let:

  • \,\eta_1 = the number of distinct operators
  • \,\eta_2 = the number of distinct operands
  • \,N_1 = the total number of operators
  • \,N_2 = the total number of operands

From these numbers, several measures can be calculated:

  • Program vocabulary:

\eta = \eta_1 + \eta_2 \,

  • Program length:

N = N_1 + N_2 \,

  • Calculated program length:

\hat{N} = \eta_1 \log_2 \eta_1 + \eta_2 \log_2 \eta_2

  • Volume:

V = N \times \log_2 \eta

  • Difficulty :

D = { \eta_1 \over 2  } \times { N_2 \over \eta_2 }

  • Effort:

E =  D \times V

The big problem with this approach is that you can’t calculate the metrics until you have written the code. This is problematic at the quotation stage of a project.

Our approach is based more on heuristics (i.e. educated guessing). By completing the following quick questionnaire we can come up with a score out of 100 which approximates the complexity and hence development effort required. This is used as an input into calculating the number of hours required and ultimately the cost.

Reefwing Complexity Matrix

  1. How customised is the user interface? Score from 0 for using the provided UI elements to 20 for a totally customised UI. Most game apps score a 20 for this, as everything from the buttons to the navigation bars need to be customised to suit the game theme. Utility apps are more likely to get a low score.
  2. How complicated is the underlying data model? This could vary from 0 for no persistent data to 20 for server based data. Using SQL or Core Data (for iOS) would be somewhere in the middle.
  3. How complex is the app? This relates to the app objective and may influence the other considerations. For example, an app with low complexity may simply display data. The other extreme would be an app that performs route mapping or language recognition. This dimension is a measure of what you are trying to do, the previous question on the data model is an element of how you are solving the problem. A lot of games can be surprisingly complex, an example of this would be if you were trying to build a decent AI for a 3D environment. Complexity will also influence how much code you will need to write which in itself will make life more difficult (have a look at the Halstead equations above).
  4. Who, what or how does the app have to communicate? You would score a 0 for this if the app was stand alone. The score would rise with the scale and type of networking required. You would also take into account how the networking was performed (e.g. Bluetooth, Wi Fi, etc) and how robust it needed to be (redundancy?).
  5. Does the app require 3rd party libraries or API’s? This could be ad servers, geo location, language recognition, translation services or anything similar. Score 0 for none and increase the score based on the number of interfaces. We also vary the score based on the maturity of the API and the API provider.

Once you have calculated your complexity score by adding the results from the five questions above you will get a number out of 100. We segment our apps into the following categories:

  • > 80: Insane:: You probably need to double the price you first thought of. Complexity increases exponentially (not linearly) with added elements because they all interact with each other.
  • 60 – 80: Difficult:: In this range you would double check everything and ensure that you have a tight specification. This app will likely take you longer than you expect and throw up things that you don’t expect. Add an extra 25 – 50% contingency.
  • 40 – 60: Average:: Most apps will fall into this range, no extra contingency should be required as long as the specification is solid and you have wire frames.
  • 20 – 40: Easy:: Should be a walk in the park. A good place for beginner developers to start.
  • 0 – 10: Simple:: There can never be too many fart apps.

We haven’t seen any other attempts to model app complexity but we would love to hear about the practices or thoughts of other developers.

Leave a Reply

Your email address will not be published. Required fields are marked *