Is there a difference between stability and reliability (at least in software engineering context) or can they be used interchangeably? If not, what would be some examples of reliable but not necessarily stable systems, and vice versa?
Are the terms stable and reliable interchangeable
system-reliabilityterminology
Related Solutions
Wikipedia's definition of an Algorithm:
In mathematics and computer science, an algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function. Algorithms are used for calculation, data processing, and automated reasoning.
Algorithms can be described in various ways, from pure mathematical formulas to complex graphs, more times than not, without pseudocode.
Pseudocode describes how you would implement an algorithm without getting into syntactical details.
So no, they're not really synonymous.
Is software development engineering? If no, what are the things that it lacks in order to be qualified thus?
Yes, software engineering is an engineering discipline.
Wikipedia defines engineering as "the application of mathematics, as well as scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations." The result of software engineering is a software system that can improve the lives of people, and it can involve some combination of scientific, mathematical, economic, social, or practical knowledge.
In terms of how it's viewed, academically and professionally, it varies. Software engineering programs can be accredited by ABET as engineering programs. Software engineers can be members of the IEEE. Some companies consider software engineering to be an engineering discipline, while others don't - it's a toss up, really.
The best book on this subject is Steve McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. It looks at software engineering as a profession, evolution from a craft to a profession, the science of software development, the difference between software engineering and software engineering (applying engineering practices to software versus engineers who happen to build software, with a case study that includes my alma mater), certification and licensing, and ethics.
Glenn Vanderburg has a series of talks called "Real Software Engineering" that has has given between 2010 and 2015 at a number of conferences, along with two related talks, "Craft, Engineering, and the Essence of Programming" (given in 2011 as a keynote at RailsConf) and "Craft and Software Engineering" (given in 2011 at QCon London). I think these talks are a pretty comprehensive argument for why software engineering is an engineering discipline.
One argument, which Vanderburg brings up briefly in his talks, is the one made by Jack W. Reeves in 1992 (and revisited again in 2005) on what software design is and how code is the output of software engineering design activities (this is also discussed on the C2 wiki). Once you get away from older schools of thought where specification and modeling is software design and into code being software design, some of the relationships between software engineering and other engineering disciplines become more readily apparent. Some differences and the reasons for those differences become even more apparent after you see that economics of software development are vastly different than many other disciplines - construction is cheap (almost free, in many cases), while design is the expensive portion.
Is that [CMMI] something that will turn development into engineering?
No. CMMI is a process improvement framework that provides guidance to organizations on what kinds of activities are useful when building software. Engineering disciplines typically have an engineering process. Having such a process is important for the successful completion of high quality projects. That said, the CMMI (or any other process framework or methodology) is just a single tool - using it won't make you magically advance from a developer to an engineer. However, not following some kind of process is, in my opinion, a sign of a project that is not an engineering project.
Also, what is your opinion on the software engineering courses/certificates?
It's only as much value as other people put into it. There are useful courses and there are useless courses. There are valuable certificates, and certificates that aren't worth the paper they are printed on. There are a lot of factors, from who is endorsing or accrediting the course or who is issuing the certificate to your current industry of employment to your current job and where you want to go.
Related Topic
- Computer Science – Difference Between Layer of Abstraction and Level of Indirection
- Terminology – What Are Frameworks, Stacks, and Middleware?
- The difference between a software process model and software engineering methods (methodology)
- Difference Between Immutable and Const
- Design Patterns vs Principles – Understanding the Differences
- Software Terminology – Differences Between Modules, Plugins, and Extensions
Best Answer
Let's say for instance we have an app, it works perfectly, aside from it crashing every 5 minutes, but it's back up instantly without data loss.
That in my mind is reliable, but not stable.
I can rely on it not losing data and working correctly, despite it not being stable.
In fact, the internet is basically that. It's far from stable—connections drop and reappear, packets collide and are lost, and all kinds of other unstable things happen. However, it's pretty amazing how reliable it is given all the instability inherent in it.