Software’s Journey: Evolution, Challenges, and Myths
The Dual Role and Importance of Software
Software plays a dual role: it is a product that delivers computing power via hardware, and it is the vehicle for delivering these products. Software acts as the basis for controlling the computer (Operating Systems), communicating information (Networks), and creating and controlling other programs. Fundamentally, software delivers what is considered the most important product of the 21st century: information.
Historical Eras of Software Development
First Era: Early Development (Approx. 1950s-1960s)
- Software was custom-developed for specific tasks.
- Distribution was limited.
- Software primarily focused on batch processing without direct user interaction.
Second Era: Multiprogramming & Products (Approx. 1960s-1970s)
- Concepts of multiprogramming and multi-user systems emerged.
- The first real-time systems appeared (data capture, analysis, and response within set times).
- Databases were introduced.
- Software began to exist as a distinct product.
Third Era: Distributed Systems & PCs (Approx. 1970s-1980s)
- Hardware costs decreased significantly.
- Distributed systems appeared, allowing different machines to process information concurrently with synchronization.
- Software consumption increased dramatically.
- Microprocessors emerged, incorporating intelligence into more devices.
Fourth Era: Networks & Objects (Approx. 1980s-Present)
- Powerful personal computer systems became widespread.
- Object-oriented technologies gained prominence.
- Expert systems were developed.
- Large computer networks were created.
Persistent Software Development Challenges
Despite these advancements, significant problems with software persist:
- Software progress continues to lag behind the potential offered by hardware advancements.
- The availability of skilled programmers does not keep pace with the increasing demand for new software.
- Software is so extensively used that failures can cause widespread economic disruption and even endanger human safety, as it’s deeply integrated into business activities.
- Maintaining and enhancing existing programs is often complicated due to poor initial designs and inadequate documentation.
Improvements regarding these problems can primarily be achieved by applying standardized software engineering practices.
Evolution of Software Engineering Practices
Early Stages (Pre-1960s)
Initially, computer programming was considered more of an art form, lacking systematic methods for building software products.
Structured Approaches (1960s – Late 1970s)
- Focus shifted to software as a product and its maintenance.
- Various technical advancements appeared, leading to more structured approaches.
Formal Methods & Design (Late 1970s – Late 1980s)
- A proliferation of various techniques and formal design methodologies occurred.
- Towards the end of the 80s, Object-Oriented Design (OOD) emerged.
Object-Orientation & CASE (1990s)
- Object-Oriented (OO) technology was strengthened and widely adopted.
- Computer-Aided Software Engineering (CASE) tools were developed.
- The explosion of the World Wide Web (WWW), Intranets, Java, and related technologies significantly impacted development.
Common Software Development Myths
Customer Myths
- Myth: A general statement of objectives is sufficient to start programming; we can provide the details later.
- Fact: A poor initial definition causes significant wasted effort and rework. A clear and detailed definition is crucial from the beginning.
- Myth: Business requirements constantly change, but software is flexible, and these changes can be easily accommodated.
- Fact: The impact and feasibility of incorporating changes depend heavily on when they arise during the project lifecycle. Late changes can be costly and difficult.
Management Myths
- Myth: We already have a document with all standards and procedures, so the development team has everything it needs.
- Fact: Simply having standards documented does not guarantee they are understood, used, or effective. Standards must be practical and actively applied.
- Myth: If planning fails or we fall behind schedule, we can always add more programmers at the end to make up time.
- Fact: Adding programmers late in a project, especially to a delayed one, often increases communication overhead and can further delay the project (Brooks’s Law).
Developer Myths
- Myth: Once I write the program and make it work, my job is done.
- Fact: The majority of software cost and effort occurs after the initial development, in maintenance, enhancement, and support. The sooner coding begins without proper design, the longer it often takes to complete correctly.
- Myth: Until the program is finished, quality cannot be assessed or controlled.
- Fact: Quality assurance activities (like reviews, testing, and adherence to standards) are necessary throughout the entire project lifecycle, starting from the beginning.
- Myth: The only deliverable required is the working program.
- Reality: Comprehensive documentation (design specifications, user manuals, test plans, etc.) is also a critical deliverable for usability and maintainability.