FREE ESSAY ON NO SILVER BULLET

NO SILVER BULLET

Abstract
The objectives of this essay are to examine whether or not Brook's original scepticism
that "no single new development in the next ten years would give software developers an
order-of-magnitude improvement in productivity, reliability, or simplicity" and
"...future progress depends upon addressing the data" are reversible. We will discuss
Brook's original thoughts and we will try to give alternative solutions (if any). This
essay, in general, accepts Brook's thoughts as he worked on OS/360 one of the most known,
for their size, software projects.
Introduction
Before we discuss what Fred Brooks is arguing, we ought to refer to the differences
between software engineering and programming. These two concepts are, in fact, totally
different. On one hand, programming is primarily a personal activity while on the other
hand software engineering is essentially a team activity. In other words, a software
engineering team, which is working on a project, may consist of many programmers. On the
contrary, a programmer writes a complete program while a software engineer writes a
software component that will be combined with components written by other software
engineers to build a system. Furthermore, the component one writes may be modified by
others in the software engineering team and it may also be used by others to build
different versions of the system long after one has left the project. Finally, we must
say that programming is just one aspect of software development.
Most of the projects, including software projects, are usually running out of time, the
budget limit is much higher than it was prearranged and also the delivered product is not
remarkable. For that reason, before a project is implemented its objectives, scope and
deliverables should be addressed and defined. It is very important to have a clear
understanding of what you are going to build and the most important thing is to build it
on time.
At this point it would be quite interesting to make a historical background. In the 1950s
and early 1960s a program was considered to be satisfactory if it executed and if it was
able to give an acceptable answer. We should always bear in mind that the amount of
memory that was used by the computers did not give to people the opportunity to run large
and complex programs. So, the key in writing a successful program had only to do with the
skills of the programmer. As the years were going through, new memory technology was used
which allowed larger programs to be executed. Thus, when people decided that the time has
come to build complex programs only then they realise how difficult was to monitor large
software projects. After this event it became quite clear that as the program size
increased the probability of error increased even faster. So the problem of managing
large software projects exists even in our days and we are unable to predict when it is
going and if it is going to find a solution.
Analysis
Software engineering technology was born when we realised that we were not capable of
managing large software projects. This situation was referred to us, as "software crisis"
and it was characterised by many symptoms. The most visible symptoms of the software
crisis have to do with late delivery of the product, over budget and also that product
does not meet specified requirements. For all the above reasons, software engineering was
seen as the cure to crisis resolution.
Fred Brooks in his seminal paper, "No Silver Bullet-Essence and Accident in Software
Engineering", is profoundly discouraging to those who are trying desperately to find an
end to "software crisis". He argues that crisis is inevitable, arising from software's
'essence' (the difficulties inherent the nature of the software) and not the 'accidental'
(the difficulties that attend its production but are not inherent the nature of the
software) that much. Brooks believes that the key to "software crisis" is addressing the
'essence. His conclusion derives from considering the inherent properties of this
irreducible essence of modern software systems: complexity, conformity, changeability,
and invisibility. The idea is that if we can specify what is inherent the software
process implementation then we will have a context within which to address the accidental
problems that limit our productivity.
Software engineering's emphasis on processes for fabricating software products, as
distinct from emphasizing the products themselves, has clearly provided useful language
and methodological improvements. But it has not provided, and seems increasingly unlikely
to do so, a fundamental solution to the software crisis. Brooks made the same point when
he argued that technology would not provide a silver bullet for the software crisis
within the foreseeable future.
Software is very difficult to produce for a lot of reasons. Firstly, software is an
invisible medium and only when it is almost finished we can have a complete view of the
delivered product. In other words, it is only towards the end that the developer and the
customer are able to discover if the delivered product is satisfactory. The second reason
is that software projects seem to be extremely difficult and complex to manage and
construct. To be more specific, a software system consists of hundreds of procedures that
are very difficult to monitor. The complexity of software is an 'essential' difficulty,
which is very difficult to annihilate but we should, at least, try to limit. One way to
limit the complexity of software is to have many people, with the same level of
knowledge, working on the software construction. The reason for having many people, with
the same level of knowledge, working together is that you can minimise the gap between
their thoughts.
'Changeability', is another 'essential' difficulty that Brooks is referring to in his
paper. To this difficulty it will not be wrong to add another one, which is 'the high
cost of software' that is part of 'Changeability' and it will be explained later the
reason for associating these two difficulties. First of all, we ought to say that
hardware development is so fast that makes software development looking very slow. For
this reason, software is very soon out of date. Furthermore, we have to decide whether we
want to spend money on maintaining the existing software or building new one. Both
decisions are quite dangerous and the biggest problem is that they both have a high cost.
It is not an accident that most of the money spent on software involves the maintenance
of it. Nevertheless, the problem is even bigger if we consider that the size of software
systems being created has increased. This means that the cost for either updating or
building new software will be quite high.
As we have already mentioned before, 'essence' and 'accident' are the two properties that
make the development of a software project so difficult. Brookes believes that there is
only one way to manage large software projects and that is to address the essence so, he
believes is that "no silver bullet is possible but several advances when working together
will increase productivity greatly but there is no single development that will do it
alone."
Brooke's scepticism was based on the complexity and other inherent qualities of software,
and on his perception that upcoming advances, such as object-oriented programming,
time-sharing, automatic programming, graphical programming and artificial intelligence,
would yield only marginal improvements. Moreover, Brooks allowed in his paper that a
combination of more fundamental changes like buying ready made components in the newly
developed mass market, rapid prototyping of applications, incremental development, and
cultivating great software designers in programming organisations, could improve
programming by an order of magnitude or more.
Brooke's fundamental changes have a lot of advantages. Firstly, we always have a working
system even if it is limited or even if it is not exactly what we would like to have but
of course it is better from nothing. Furthermore, code is being continually debugged to
make sure that is running. Another advantage is that the problem area can be easily
located as being probably in the segment just added. Last but not least important, this
technique is applicable to large and small systems as well.
Another point that was mentioned by Brookes to help the managing of large projects
involves the need to have good program designers. Experienced are not always the most
suitable designers for your project. So, we should always look for those programmers that
correspond to the needs of the particular project that we are going to build.
Brooks had his own experience on software projects as he worked on OS/360 one of the best
known, for their size, software projects. This project was released with many errors, it
was behind schedule, took more memory than it was planned, cost a lot more money than it
was estimated and early releases were not working properly. Later on, the emergence of
Software engineering changed the ratio of hardware and software costs and helped in
maintenance of the software. Furthermore, advances in hardware (integrated circuits,
magnetic disks, and microcomputers) have increased the demand for software. Advances in
software techniques (multiprogramming and time-sharing) lead to more ways to use
computers. Brooks by using his own experience on large projects argues that the goals of
Software engineering are: Firstly, to produce quality software, secondly with low cost
and lastly to produce the deliver product on time.
Conclusion
To sum up, we ought to accept that no silver bullet is possible to be found in the near
future. Although, we should be hopeful that techniques for limiting this problem are
possible to be discovered. One technique that is suggested by Brookes has to do with
addressing the 'essence' but this is not the only one. Form what history has shown us up
to now people learn from their mistakes, so it is possible that in a few years time other
more effective techniques can be detected in order to manage large software projects.
Basically, I believe that the gap between the hardware and the software progress is one
of the biggest problems that we are up to. As the costs of storage and CPU cycles become
insignificant relative to personnel costs, the hardware terms nearly drop out of the
equation of trade-offs in software design. Thus, the human challenges of managing
software's complexity - presenting a coherent interface to the user, and co-ordinating
the efforts of the development team - remain formidable for developers of today's big
systems.