Loading...

Summary of "No Silver Bullet. Essence and Accident in Software Engineering" by Frederick Brooks, 1995

Abstract 2016 7 Pages

Computer Science - Software

Excerpt

Content

Introduction

Essential difficulties

Complexity

Conformity

Changeability

Invisibility

Solved accidental difficulties
High-level languages
Time – sharing

Hopes for the silver
Ada language
Object - oriented programming (OOP)
Artificial Intelligence (AI)

Expert Systems
Automatic programming
Graphical programming
Program verification

Promising attacks on conceptual essence

Relevance of “No Silver Bullet” today

Conclusion

References

Introduction

Software engineering has its limits. No piece of software that has been build in the past is error-free or completely reliable. There is a need in the software engineering field for software development methods which would produce simple and reliable software.

Essential difficulties

Software is currently not being developed with a mindset of tackling software engineering issues like “conformity, changeability, flexibility, invisibility and complexity”,(Brooks, 1995).

In the past, software has depended on hardware to run smoothly without malfunctioning but nowadays hardware technology is advancing rapidly by the day and becoming cheaper by the minute. However it is the opposite for software engineering, it is becoming more difficult to keep up with the advancement of hardware technology to the extent that software engineers do not bother to build software that can match up the capabilities of the current hardware capabilities.

Complexity

The software engineering field in itself is growing, young minds are coming up with more complex programming languages to solve real life issues where applicable. Each programming language has its own specific purpose in a piece of software resulting in more complicated functions. This means a single software project can have more than five different programming languages performing different tasks which further contribute to the complexity of the functions and the software itself.

Although complex software tend to perform complex tasks, this however makes it difficult for the software to be integrated into another piece of software or advanced in some way without having to re-write majority of software functions which would in-turn cause more errors, increase costs of software maintenance that need to be dealt with in the future.

Conformity

Every software piece ever written has to run somewhere, it has to fit-in somewhere where there have been other software systems running long before the new software was built. Software often has to be interfaced with older systems built before the current software, this makes it rather difficult for software to perform they way it was built to perform because sometimes it does not fit-in with older systems.

Changeability

As to everything in the world, software also has a lifetime. There comes a point in a software's life-cycle where the functions and capabilities of a software need to change or improve. People are becoming wiser as the years go by, meaning people would start recognising the incapabilities of everything out there including software since our jobs and lives merely depend on it. This means a piece of software or software functions are dependent on the technological advancement of its surroundings.

Invisibility

Unlike any other object, software can not be viewed from a bird's eye view like any object drawn in a 3D CAD(Computer Aided Diagram) system. This inability contributes to the limitations of software engineering. Software engineers tend to just build a piece of software without having a clear idea of how the final product would look or perform since there is no way to visualise it before development, which is why there is a need for a prototype to lay out the major functions of the software that seem impossible to complete.

Solved accidental difficulties

High-level languages

High-level programming languages have made it easier for people to learn programming and write the famous “Hello World!” without much struggle. High-level languages are more concerned with what a user sees on the front-end of a software and how each function accomplishes a certain task rather than focusing on which register stores a particular process running in a software as lower-level languages do. High-level languages are close to plain English, this factor has contributed to the rapid growth of programmers around the world, therefore solving some of the issues in the software engineering field.

Time – sharing

As more people learn how to program, they start sharing insights and start to use a variety of communication medium to put their work out there for anyone to access and get solutions for problems they have been experiencing in the past.

Hopes for the silver

Ada language

(Brooks, 1995) argues that Ada programming language and high-level languages are promising to tackle some of the issues experienced in software engineering, Ada was specifically designed for system functions where overall system efficiency and reliability is vital.

Object - oriented programming (OOP)

Object – oriented programming is one of the advancements in programming that has made it easier for programmers to define variables or objects in this matter. Each object would be defined on the basis of what data structures would be stored in it to serve a purpose in the program or software. Examples of widely used object – oriented programming languages would be C++ and Java.

Artificial Intelligence (AI)

(Brooks, 1995) argues that Artificial Intelligence is not what people are expecting it to be, it is merely just computer hardware and software processes which choose the best solution in a given problem likely to be chosen by humans.

Expert Systems

Every software system should be designed and built in such a manner that it would be able to test and diagnose itself when it malfunctions, However this would not be an easy task to implement. Building an expert system would require very knowledgeable programmers which could build a general system to solve multiple complex tasks.

Automatic programming

It is essential to have software systems that are able to program themselves, and write program solutions of problem from a problem statement automatically.

Graphical programming

According to (Brooks, 1995)⁠, presentation of software functions in a graphical manner does not contribute to the simplicity of having an overview of a system since diagrams like flow charts tend to be bigger than a normal screen size of a computer. Furthermore, software functions are often more complex than they seem on a flow chart.

Program verification

Program verification is where most programmers spend time and it is one of the most important steps in a software life-cycle. Verifying a program before the testing phase can eliminate a lot of anomalies, it could even reduce the time spent on testing the actual software because each requirement would be verified before being implemented.

Environments and tools

Given the amount of tools available in this modern day to write software, there is no excuse as to why software engineers keep producing unreliable and unmaintainable software. Each programmer can program on any environment they feel comfortable, there are no limitations.

Promising attacks on conceptual essence

As the large number of software engineers increases daily, there is more competition, more software available for anyone to utilise freely, this benefit means that whatever software one is trying to build may already be out there somewhere.

People are always trying to get things done as quick as possible, even though software engineers are to write their own software, more often it makes sense to purchase what is available out there rather than building something that has already been built.

Part of every software development model is defining the requirements, this part of a software life-cycle outlines all the necessary functions or task which the software should complete, this is where the complexity of a software project is weighed. Among software engineers, it is a known fact that “customers never know what they want”.

[...]

Details

Pages
7
Year
2016
ISBN (eBook)
9783668218505
File size
385 KB
Language
English
Catalog Number
v321505
Grade
Tags
summary silver bullet essence accident software engineering frederick brooks

Author

Previous

Title: Summary of "No Silver Bullet. Essence and Accident in Software Engineering" by Frederick Brooks, 1995