Question 01: Two Parts

1) Software programs have insidious problems. What & why?

Look ahead.

2) Should we blame the programmers?

The answer: No.

We need to engineer the programs instead of programming them.

How many software programs are there in the world? Joseph Newcomer, Former Chief Software Architect (1987–2010) and Author have 14.7K replies and 3.7M answer views. Billions. Probably not trillions. But certainly, more than hundreds of millions. Some are one line long. Some are a hundred million lines long.

These software programs have insidious problems, such as:

• Lack of reliability.

• Lack of stability/unstable

• Excessively costly (billions) to build, purchase, and operate.

• Brittle

• Software projects continue to fail at an alarming rate.

This data immediately prompts two questions:

1. Is it a problem with the project methodology or how organizations administer software engineering projects?

2. Is it a problem with the quality of software engineers available within the marketplace?

There is plenty of blame; however, these are not the root causes of the failings of contemporary software applications and software products.

The problems are manifold:

(1) Every software solution must be targeted for an operating platform, and invariably, a software engineer or team of engineers must build out not only the functional capabilities of the software but also must deliver the plumbing of the software itself. The multitude of questions must be addressed at the commencement of a software engineering project:

I. How does information move within the application?

II. What algorithms and patterns will be used, and which will be avoided?

III. How do different components interact?

IV. Is there a need for a message bus?

II. Will the application employs services?

VI. How is information stored, retrieved, rendered, reported, and transmitted to consumers of other details?

V. What are the performance requirements of the application?

VI. What is the mechanism for recovering from routine application failures? Or catastrophic failures?

VII. How do we prevent the application from suffering from design constraints that effectively lock the application from evolving to meet changing requirements over time?

VIII. How can we prepare for inevitable changes in requirements and ensure the integrity of the application across many design changes?

(2) Functional and non-functional requirements must be vetted, and a solution that satisfies these questions and many more is needed. Plus, there needs to be a holistic methodology for efficiently documenting a software application's functional and non-functional requirements, neither at its inception nor throughout its lifecycle. Approaches to writing these requirements are as diverse as the number of software architectures today. For example, Fayad's Unified Software Engine (FUSE) employs a holistic approach to Unified and Stable Functional and Non-Functional Requirements Ultimate Design, Unified Software Architecture on-Demand (USA on-Demand); and applications are simply artifacts of the entire lifecycle of the system and application software.

Note: We have a complete in-house course on FUSE and will post a few PowerPoint Presentations and videos related to FUSE soon.

We could spend hundreds of pages analyzing the many weaknesses of contemporary software engineering practice, but the purpose of our research is different. The compendium of research into the failures of modern software methods is vast, and each new methodology and technique introduced addresses point solutions to only specific problems and weaknesses in software engineering. Unfortunately, no unified and holistic software approach addresses the issues with prior methods.

One may ask, "how so?" or "how did we get into this desperate situation? Unfortunately, this specific line of questioning perpetuates the problem and keeps the software engineering community on the wrong track. The question pre-supposes that minor tweaks to how software is engineered are adequate to "fix" the problems that genius software engineers have bequeathed to our world. We cannot just tweak things as has been tried before. We cannot replace zero methodologies with waterfalls to fix how projects are managed. We need to replace waterfall with agile and get a better outcome.

We have made meaningful advances in Software Engineering in the past 50 years. Waterfall methodology was an essential improvement over the diverse approaches used before Waterfall methods were introduced. Object-Oriented Analysis, which led to Object-Oriented Design and Object-Oriented programming, was a similarly crucial step forward. This object orientation motivated the Gang of Four to introduce their notion of systems of patterns, ushering the concepts of patterns into the contemporary world of software engineering. So pervasive was this concept and so widely adopted that it is unlikely to find any software undertaking that does not employ the idea of patterns today.

However, if this is the case, why are the artifacts of software not improving markedly? Why do we still have failures with alarming frequency across all software projects? Shouldn't we expect more from software projects that employ the correct techniques and methods? However, again, this is the wrong question. It assumes that we can adjust a small error here or there.them.