Human factors risk in software and web application development
In any complex engineering project, there is risk to project success and delivery at every stage from design, to development, to maintenance and beyond. Risk factors in systems increase with greater complexity and complexity itself is driven by the density and interaction of and between component parts whether that be when viewing the overall system, sub systems or sub sub systems etc.
Due to the fact that software architecture involves potentially hundreds of thousands, if not millions of lines of code, the risk factor is extremely high due to the shear number of component parts (individual lines of code) required to perform multitudes of required actions. In fact, in terms of risk calculation of project success, software engineering is amongst the highest risk engineering fields in the world; up there with nuclear engineering and aviation and especially if the software is for safety critical functionality. Risk in software development certainly cannot be taken lightly.
In modern software systems an Object Oriented (OO) approach is used, as opposed to the amateurish procedural style code, and they are commonly structured in the form:
single line of code (SLOC) > units of SLOC > methods/functions > classes/objects > group of objects > sub-sub-system > sub-system > system > application.
If utilised correctly, the use of OO in software engineering and an architecture based around the one above reduces risk due to encapsulation, modulation and re-usability of code.
Moreover, using recognised international standards of software development (ISO 12207), where software engineering is split into acquisition, supply, development, operation and maintenance stages, and has been introduced professionally after decades of user experience, also reduces risk in software engineering projects.
But, this all sounds incredibly academic; we are missing one key ingredient in this approach – and that is the human! So, how does Human Factors fit into your Software Engineering plan?
What is Human Factors?
Gong back 10 years now, I landed a great job at Serco Group Plc based in Birchwood Park, Warrington as a Risk and Safety Consultant. As part of this, myself and the other fresh faced new starters were put on a series of courses – one of which was Human Factors Awareness. We were all sceptical and to be honest thought it sounded a bit arty farty – but we were wrong. Serco were clever in introducing this to us early on, as this relatively simple concept meant we always brought the human side of things into risk and safety calculations, during what were largely heavy-engineering based projects where we were traditionally analysing systems based on valves, pumps and pipes. In fact I learnt early on that introducing Human Factors into my quantified risk and reliability assessments significantly altered the risk scores. For example, take a pump – it will fail say 1 in 2000 times: fairly easy to calculate, but, what about the worker who has to operate the pump? How does his involvement come into this calculation? I doubt many of us would have naturally thought of that side of things without knowing a bit about Human Factors.
So what is Human Factors exactly?
Human Factors as taken from Wikipedia is- the scientific discipline concerned with the understanding of interactions among humans and other elements of a system, and the profession that applies theory, principles, data and methods to design in order to optimise human well-being and overall system performance.
In terms of software development, we are concerned specifically with how human interaction and involvement in the development process can affect system success.
How do you calculate Human Factors risk?
In risk calculations, you need two key pieces of information: 1) Probability and 2) Impact. There are various schools of thought on the probability side of things, but I have always found a good rule of thumb is 1 in 1000. i.e. a human will fail at the same task every 1 in 1000 times. For example, if you walk up and down a flight of stairs 1000 times, you could in theory trip on one of the steps in that period. Impact is slightly difficult to calculate in Human Factors because the impact is usually downstream e.g. If you forget to turn a pump on 1 in 1000 times, the impact of not turning on the pump is dictated by the pump itself. For this reason, and for ease and simplicity, it is a good idea to use an impact factor of 1. If we knew that we we're going to trip up at some point within 1000 steps, we would do something about it – we would, like in any risky event, add a risk control. In this case we might just add a sign at the bottom of the steps saying “please be careful not to trip on the steps” and this might be enough to reduce the risk so we may now trip 1 in 5000 times.
1 in 1000 sounds quite a low probability, what 's the big deal?
If there are two people working on the same project but on different tasks; assuming there are no risk controls put in place, each of them has a 1 in 1000 chance of making a mistake – we now have a 2 in 1000 chance of introducing errors – well that's now 1 in 500. With four people you are now down to 1 in 250 and so on. Quite quickly you can see how collective Human Factors risk , left uncontrolled, increases.
How does this relate to software development?
As discussed above, software development requires the formulation of thousands of lines of codes, all interacting to certain degrees, to eventually produce a range of desired functions and outcomes. If we have a team of four, directly or indirectly involved in the development of the software, and we have already calculated a failure rate of 1 in 250. That means there will be a mistake in every 250 lines of code – clearly that is unacceptable. In a software system of 100,000 lines of code, that's 400 errors in one system which would without question equate to a catastrophic failure.
It is therefore important, in software development, due to the vast numbers of lines of code, and subsequent high probability of introducing errors that you utilise several layers of human factors risk control:
High quality technical recruitment - minimise the risk of introducing errors directly into your code by testing all potential developers for technical ability. If you do not have the capability to test developers yourself, hire a reputable software consultancy to do it for you. Only ever recruit developers who have been peer-reviewed to some degree.
Always use ISO 12207 from the outset to manage your software - adopting ISO 12207 takes care of a lot of the human factors errors in software development. ISO 12207 has evolved over decades and from the collusion of thousands of experienced developers who have seen all the pitfalls associated with software development and have worked out ways to safeguard against them.
Keep all your developers in the same location as much as possible - Sounds like common sense, but I have seen this a few times - developers working on the same project but in different locations. Effective communication is essential to promote project success. If this isn't possible, then formulate methods where developers can interact efficiently.