The World and the Machine is a paper by Professor Michael Jackson published in 1995 in Proceedings of the 17th international conference on Software engineering, and it changed my perspective on computer software. Alas, for copyright reasons I am not allowed to provide a copy here.

Jackson views software development as an engineering discipline concerned with creating programs to solve real world problems.  The software developed describes a machine, and turns a generic computer into that machine – a useful physical device capable of problem solving.  The true value of the software developed is measured by its usability and its ability to satisfy the requirements for which it was designed. He takes a holistic approach by saying that software developers are not merely concerned with the software artefact itself, but the establishment and definition of the real world requirements and problems the software addresses.

Jackson takes the approach that software is a machine designed to perform a useful function in the real world, and that the specification is the bridge between the world and the software. The machine has no purpose without the world because that is where the problem exists which the software/machine was built to solve. The problem is in the world not the machine, and the software cannot be developed in isolation to the world in which it will exist. For example, ATM software would be of little use if it was designed to require a mouse and keyboard, irrespective of its account management features.

A real world problem is defined in the specification, and software is then developed to meet that specification. If the specification has accurately captured the requirements, and the software meets the specification, then the software loaded into the computer will create a machine which solves the problem in the world. Interestingly, Jackson’s paper implies a strict progression from:

Problem -> Specification -> Program -> Solution

This does not take into account the fact that requirements could well change. To stay with Jackson’s view: the world, and therefore the specification, might change while the machine is being built, which obviously affects the machine’s ability to successfully solve the original problem.

Jackson views software development as an engineering discipline, and most engineering disciplines model their creations in one form or another. Modelling provides an abstraction of the real world, often free of implementation detail, which allows us to manage complexity and design a solution to a real-world problem. UML provides a standardised notation and semantics from which to create a model of a machine (at various levels of abstraction). By designing and developing the software using an incremental and iterative methodology, we can quickly assess and improve the machine to more precisely solve the problem in the world, and therefore achieve success.

In this post I am going to discuss two Software Development articles: "No silver bullet - essence and accident in Software engineering" by F. Brooks from 1987 and the more recent 2002 article "Get ready for agile methods, with care" by B. Boehm. Are Agile Software Development methods one of the "Silver Bullets" whose existence Fred Brooks questioned?

According to Brooks, the difficulties in developing software derive from it's essential complexity, need to conform to other interfaces, need to change and difficulty to visualise. As to whether recent agile methods could be a silver bullet for software development, Brooks says that there can be no silver bullet due to the nature of software, but states that there are “encouraging innovations”. It can be argued that the innovations he talks of are, in fact, essential characteristics of what later became known as agile methods. The following paragraphs compares these innovations with the agile methods in the Boehm article.

Requirements - Brooks argues that the most difficult part of developing a software system is deciding what to develop, ie establishing the requirements, the specification and designing the software, and promotes an iterative approach to eliciting and refining the requirements between the developer and client. This is comparable with the agile approach of working closely with a customer representative to establish and implement their requirements in small iterations.

Change – Brooks writes that during initial development the client often doesn't fully know their requirements for the software, that additional requirements emerge during development, and, once released, all successful software comes under pressure for change. However, Boehm tells us how agile methods welcome change as requirements emerge and change during development. Short development iterations, along with constant testing, allow changes to be incorporated into the software.

Rapid prototyping and incremental development – according to Brooks, an early prototype helps to visualise the software, allows the client to verify that it meets his requirements, allows any emergent requirements to surface, and creates a basic working system which can be gradually expanded. He also claims that getting an early prototype running boosts morale. Boehm quotes the Agile Manifesto principle of releasing software early and regularly. This gives the customer regular returns on his investment (Chromatic, 2003).

Visualisation and modelling – In 1987 Brooks wrote that software is inherently unvisualisable and attacked the usefulness of a flowchart as a design tool. However, UML and current modelling tools allow designers to create detailed models of software from which the code can be auto-generated.

People – Boehm highlights how agile methods lean towards requiring a small number of premium people, using their tacit knowledge rather than detailed plans to develop designs, and that design-by-committee often results in an inferior design. Fifteen years earlier, Brooks was saying exactly the same thing – that great software is often designed by just a few great designers rather than by committee.

Testing – Brooks states that a great deal of the effort in developing software goes into testing and bug fixing, and asks whether a silver bullet can be found which eliminates them in the system design phase, and whether this will lead to improvements in productivity and reliability. Regular testing is fundamental to agile methods. Unit testing is used to test discrete sections of code, often individual methods, whilst Continuous Integration rebuilds and tests the whole system every time a change is checked into source control, in order to check for changes in one part of the system (which might well work fine on their own) affecting other areas of the system (Niemeyer and Poteet, 2003).

Project size – Brooks claims the benefits of incremental development applies to projects of all sizes, however, Boehm's article quotes Larry Constantine as saying that it becomes increasingly difficult to apply agile methods to teams of more than 15 to 20.

In discussing Brooks' No Silver Bullet article, Black (1999) reiterates the argument that searching for a universal cure to the “software problem” is counterproductive. He goes on to reiterate that developments such as RAD, OOP and 4GLs have all had their moment as the next big thing, but ultimately become last year's incremental improvement.

In conclusion it can be argued that agile methods maybe do represent Brooks' silver bullet under certain circumstances, with the right people - designers, developers, managers and customers - and the right project. However, in Boehm's article even proponents of agile methods state that they are not suitable for very large projects or safety-critical systems, so the home grounds of the various approaches need to be matched to the project.

References

Black, R., (1999). Managing the Testing Process, Microsoft Press

Boehm, B. (2002). Get ready for agile methods, with care, IEEE Computer, Vol. 35, No. 1, January, 64–9.

Brooks, F. (1987). No silver bullet – essence and accident in software engineering, IEEE Computer, Vol. 20, No. 4, April, 10–19

Chromatic, (2003). Extreme Programming Pocket Guide, O'Reilly

Niemeyer, G., Poteet, J., (2003), Extreme Programming with Ant , Sams Publishing

In 1943 Maslow published an article on human motivation entitled "A Theory of Human Motivation", and in this post I consider how these theories might apply to those involved in the development of free open source software (F/OSS).

Maslow’s theories describe how a person’s needs are the motivators for their behaviour, and that once a given need is satisfied it is no longer a motivator. Needs are presented in a hierarchy and once basic needs such as food, safety and love have been satisfied, the person is free to concentrate on higher needs, which he presents as Esteem needs followed by Self-actualization needs. These needs then become the motivators for behaviour, and both may arguably be applied to individuals’ motivation for participation in open-source software.

Under the heading of Esteem needs, Maslow states that everyone has a need or desire for self-esteem and for the esteem of others, based on their own capacity and achievement, along with respect from others in the form of: reputation, prestige, recognition, attention, appreciation or importance. This is supported by Dale Carnegie who argues that the desire to feel appreciated and important are the deepest urges in human nature.

These esteem needs can be applied to what Lakhani describes as extrinsic motivation for participation in a F/OSS project. Herzberg’s motivation-hygiene theory places less emphasis on salary as a motivator than might initially be expected. In F/OSS one’s contribution (normally in the form of source code) indicates one’s capacity and level of achievement, and how these are perceived by peers becomes the basis for the esteem in which the contributor is held by his peer group. Raymond (2001) describes F/OSS culture as a gift culture where status and reputation are based on what is given away, i.e. contribution to the F/OSS project and/or movement.

Contributions to a F/OSS project are normally subjected to intense peer review by the project team and other interested third parties, and faults are readily, and often publicly through mailing lists, communicated back to the contributor. Nantz (2005) claims that most F/OSS developers have a desire to look good in the eyes of their peers and will refine their code to the best of their abilities before releasing it.

Once an individual’s esteem needs are satisfied, Maslow argues that a need for self-actualization can develop whereby a person is compelled to pursue their vocation in search of self-fulfillment, and where that vocation is creative it will take that form. Lakhani describes how developers often consider programming as a creative endeavour, and the survey presented in his paper noted that developers feel a high sense of personal creativity in their projects.

This self-actualization need is comparable to Lakhani’s Intrinsic Motivation, which in this context can be seen as developing F/OSS for the inherent enjoyment, intellectual challenge and self-satisfaction, rather than any external reasons. A developer can be motivated to select a problem which matches their ability, but without a pre-determined solution, the reward of their endeavours being the creative solution to the problem, and the knowledge gained from the development process. In doing this, the F/OSS developer has, through his own creativity, expanded his vocational knowledge and experience, and helped to satisfy his own self-actualization need.

In conclusion, it can be argued that the results found by Lakhani et al do approximate Maslow’s theories, however, there is an overlap in the motivational factors behind F/OSS participation. Maslow talks about the “Degree of relative satisfaction” to indicate that there is no clear point at which one set of needs is completely satisfied and the individual then progresses to the next higher level. If one considers Extrinsic motivational factors to be comparable with esteem needs and Intrinsic motivational factors to be comparable with self-actualization needs, then the Lakhani paper reports observing an interplay between extrinsic and intrinsic motivations, and F/OSS developers motivated by a combination of the two with neither dominating nor destroying the effectiveness of the other.

References

Carnegie, D., (1953). How to Win Friends and Influence People, London, UK, Vermilion.

Lakhani, K.R. and Wolf, R.G., (2005). Why hackers do what they do: understanding motivation and effort in free/open source software projects in Feller, J., Fitzgerald, B., Hissam, S. and Lakhani, K.R. (eds) Perspectives on Free and Open Source Software, MIT Press.

Maslow, H., (1943). A theory of human motivation, originally published in Psychological Review, 50, 370–96

Nantz, B., (2005). Open Source .NET Development, Boston, USA, Pearson Education, Inc.

Raymond, E. S., (2001). How to Become a Hacker [online], Available from: www.catb.org/~esr/faqs/hacker-howto.html (Accessed 04/04/2010)