The Black Liszt

Category: Software Science

  • Summary: Computer Science

    If you want to learn math, physics or chemistry, you go to the respective departments to find the people who are true, verified experts. Same with software and Computer Science. What could be more obvious? The trouble is, it’s wrong. Whatever it is they do, it has little to do with real-world software. Worse, it isn’t even a science.

    At the beginning and continuing in many universities, software was part of the math department. What could be stronger endorsement of its precision and status as a science?

    https://blackliszt.com/2015/04/math-and-computer-science-in-academia.html

    The sad fact is, math and computer science are at fundamental odds with effective software development.

    https://blackliszt.com/2015/05/math-and-computer-science-vs-software-development.html

    How does Computer Science stack up against real sciences like physics? Not well.

    https://blackliszt.com/2019/11/computer-science-is-propaganda-and-computer-engineering-is-a-distant-goal.html

    https://blackliszt.com/2019/04/software-is-a-pre-scientific-discipline.html

    Real science isn’t about experts or authority; it’s about evidence. Whatever you yammer about in academia, if there aren’t verifiable results in the real world, it’s nonsense. In the medical world, for example, drugs are subjected to a process that verifies that they do what they’re supposed to do.

    https://blackliszt.com/2015/07/the-science-of-drugs-vs-the-science-of-computers-and-software.html

    It took a long time for medicine to pay real attention to evidence. Authority and accepted practice are hard to break. For example, think about the long practice of blood-letting.

    https://blackliszt.com/2019/02/what-software-experts-think-about-blood-letting.html

    The history of scurvy and antiseptic surgery also provide lessons. Even the development of the steam boat!

    https://blackliszt.com/2014/02/lessons-for-software-from-the-history-of-scurvy.html

    https://blackliszt.com/2012/07/what-can-software-learn-from-steamboats-and-antiseptic-surgery.html

    In medicine there are studies that are peer-reviewed and published with results. This is called “evidence-based medicine.” You would think there would be the equivalent in software, wouldn’t you?

    https://blackliszt.com/2017/02/evidence-based-software.html

    The vast majority of software experts strongly resemble medical doctors from those earlier times. The evidence is overwhelming that the "cures" they promote make things worse, but since all the software doctors give nearly the same horrible advice, things continue.

    In real science, there is general recognition that what is accepted may not be perfect or complete. Sometimes there are anomalies, evidence that doesn’t support the current theory. Then there’s a paradigm shift that revises and/or replaces the accepted theory.

    https://blackliszt.com/2021/11/computer-science-and-kuhns-structure-of-scientific-revolutions.html

    Computer Science is flooded with problems that the experts largely ignore. It’s bad. If bridges fell down at anywhere close to the rate that software systems break and become unavailable, there would be mass revolt. Drivers would demand that bridge engineers make radical changes and improvements in bridge design and building.

    One of the interesting things is that Computer Scientists have sometimes acknowledged there are serious problems. For example, there was a big conference to address the “crisis in software” … in 1968!

    https://blackliszt.com/2021/08/the-crisis-in-software-is-over-50-years-old.html

    What did they do? They promoted “structured programming” and decided that the essential “go to” statement was evil.

    https://blackliszt.com/2021/09/software-programming-language-evolution-the-structured-programming-goto-witch-hunt.html

    Aside from a new wave of rhetoric in the software world, nothing of substance changed. When you compare the "batting average" of typical software project managers with baseball, the issues become extremely clear. The typical software project has trouble getting to first base, much less make a run –and the opposing "pitcher" is like the one in the home run derby, who pitches nothing but easy hits.

    https://blackliszt.com/2024/08/what-is-your-software-project-managers-batting-average.html

    It is enlightening to compare the training to became an MD to the training to be qualified in software. In medicine, your job is to keep people healthy and cure them when they’re not. In software, your job is to build healthy software and cure it when it’s not. The training and testing requirements couldn’t’ be more different. Hint: it’s way better for doctors.

    https://blackliszt.com/2020/07/job-requirements-for-software-engineers-should-stop-requiring-cs.html

    Fashion” is a word we associate with clothes. Software is hard, it’s objective, it’s taught in schools as “computer science.” Software can’t have anything to do with “fashion” if it’s a “science,” can it? Sadly, software is infected by fashion trends and styles at least as much as clothes. Fashion has a huge impact on how software is built.

    https://blackliszt.com/2018/11/what-are-software-fashions.html

    https://blackliszt.com/2019/05/recurring-software-fashion-nightmares.html

    When software history becomes as important a part of computer science education as physics history is of physics, we'll know it's approaching credibility. Until then, everything about computer science, education and practice will continue to be a cruel joke.

    https://blackliszt.com/2012/03/computer-history.html

    https://blackliszt.com/2019/06/the-evolution-of-software.html

    What can be done? One thing is to understand and accept the goals of software. In physics, the goal is to make accurate predictions of space/time events. What is the equivalent in software? There is actually widespread tacit agreement. It’s just not talked about and contradicted by the reigning dogmas.

    https://blackliszt.com/2022/05/the-goals-of-software-architecture.html

    Until such time as Computer Science becomes scientific, no one who wants to do software should bother with academic degrees, and anyone hiring for software should not require a college degree, much less one in Computer Science. The degree isn't worth as much as you night think.

    https://blackliszt.com/2015/05/how-much-is-a-computer-science-degree-worth.html

    Things will get better only when there is wide acknowledgement of the fact that today's Computer Science is LESS scientific than … ready for it? … cat litter.

    https://blackliszt.com/2023/12/cat-litter-is-more-scientific-than-computer-science.html

     

  • The Evolution of Software

    There is strong interest in the latest developments in software. No one wants to be left behind.

    At the same time, there is a peculiar (to me) lack of interest in whatever the latest thing grew out of or evolved from. What are the new thing's predecessors? What did that thing grow out of. Have similar things appeared in the past? Are there patterns we can observe here, or are the new software things that explode onto the scene just a meaningless sequence of random events? Are they things that we obsess about while they're here without questioning or wondering where they came from, without asking what else they may resemble in some way? Are they things we just forget about and ignore once they depart the stage of software fads?

    The questions have obvious answers. Answers that no one seems to be interested in.

    So long as we fail to ask these crucial questions, we will remain ignorant of software in deep ways, and will continue to stumble from fad to fad without improvement or understanding. History is important!

    Evolution in Science

    If you study different sciences and their history, you notice that, at some point, scientists begin to pay attention to evolution, i.e., change over time of the thing being studied.

    The most obvious thing is evolution of an individual item over time. In biology, you have the cycle from birth to death. In geology, you have the change of mountains, rivers, beaches and glaciers. In materials science you have the change of objects as they are subjected to various conditions over time, for example the way that iron rusts.

    Evolutionary studies reach a breaking point and get really interesting when you study groups and types and see the patterns of change. In biology, this was the revolution that happened with Darwin and his study of the evolution of species. Something similar happened in geology with plate tectonics.

    When you put the patterns together, things get totally amazing and transformative. While no longer fashionable to talk about and study, the parallels between the growth stages of an individual animal and the evolution of species are obvious, though not literal at a detail level.

    Studying evolution is an important stage in the evolution of most sciences!

    It's long-since past time to study software evolution, as an integral part of software science.

    Software Evolution

    Software evolves at every level.

    At a basic level, software languages evolve. I have given an introduction to this subject here. The evolution of software languages resembles biological evolution in remarkable ways, as species (languages) emerge and evolve in response to new conditions, including other species. Similarly to biology, languages evolve; sometimes many species descend from them; and sometimes a species goes extinct. See this snapshot, for example:

    11

    (Credit)

    Consistent with the determination of nearly everyone involved with software to ignore its history, this chart and anything like it are ignored, and the evolutionary principles behind it are not studied. When you start to study them, you learn amazing things. Suddenly some of the random change in the world of software languages starts to make sense.

    Software languages are the very most basic things about software. Just as interesting and vastly more important are the programs written in software languages. Everyone involved in writing or maintaining a software program (application) just thinks about that program. It definitely occurs to business people what the program can do compared to its immediate competitors, if any. Yes, there is a kind of "survival of the fittest" in software evolution.

    What about the "insides" of the program compared to other program insides? Sometimes people are aware of gross differences, like the language the program is written in. But the curiosity normally stops there.

    The program "insides" have huge practical consequences. Depending on the details of how a program is written, it can be more or less:

    • reliable/buggy
    • easy to hack (secure)
    • expensive to run/operate
    • dangerous/costly to change
    • able to respond quickly to changing loads
    • speedy or slow

    People commonly talk about structure or architecture, but those things are just the tip of the iceberg.

    When you dig in, you find the equivalent of islands and continents of software. I've treated this subject here, for example. For example, you may have spent some number of years after getting your CS degree working on website design, and interacted with a community of people similarly engaged. Not everyone uses the same tools or does things the same way, of course, and you're likely to think there's quite a variety of approaches.

    Then you go wild, dive into hospital management systems, and your mind is blown. What you thought was the wide variety of software and tools used by website designers turns out to be a whole continent apart from what you find in hospital automation. You learn that the flagship product of the company that has more than a third of the market (Epic) is written in a language you've never even heard of! It's like growing up in New Jersey among what you think is a very wide variety of people and going to Chennai — a huge city in India you've never heard of, whose population is larger than your whole state, where the main language is one you've never heard of, written in a script you've never before seen.

    Even more ignored are the obvious (to those who trouble to look) repeating patterns that can be observed in applications as they are first written and then evolve over time.

    The Study of Software Evolution

    To put it bluntly, the study of software evolution has barely begun. A few isolated souls, hardy or foolhardy as you like, have dipped their toes into the deep waters of software evolution. Those few have found worlds to explore, oceans whose depths have yet to be plumbed.

    This is particularly the case because software is a "the only reality is the present" kind of field, as it now stands. It doesn't have to be this way!

    Very few people study the history of math. They don't need to: anyone who learns math starts with math as it existed thousands of years ago. If they do well in math, they get all the way up to … the late 1600's, when Newton and/or Leibnitz discovered calculus! Each step in math is based on and often depends on the earlier steps.

    In some sense, this is also true of software. Except not really.

    First, knowing nothing about software, you can dive right into the latest language and tools and use them to make something that works. Anyone think you could do that with differential equations, I mean without already knowing how to count, add and multiply? The difference is that in software, the "accomplished" new-comer really is standing on generations of older software … of which s/he is blissfully unaware! The new programmer, of course, uses an incredible array of operating systems, drivers, networking, file and database systems, and on and on. These form the "land" on which the new programmer "stands" to work. None of the wonderful new stuff would work without it. The big difference, of course, is that using the underlying software and understanding the underlying software are two rather different things. This makes software totally different from not just math, but most of the other legitimate sciences (leaving out the fake ones like political "science" and the rest).

    Second, when you're building a program, chances are excellent that you're not the first person to try building something very much like that program. Lots of details may be different, but even the details are probably not as unique as you might think. Suppose you need a program that sets up an account for a person, and then when the person does stuff, the details are checked with the person's account, and if OK are added to the account, and if not are rejected but recorded. This high-level description applies to a sales operation with customers, a medical office with patients, a manufacturing company with customers, and a bank. Given that programs like this have been built tens of thousands of times, don't you think that the ways of building programs like this would have evolved? That there would be pre-built parts, specialized tools for using the parts, building new ones and gluing them together? Special methods that have evolved and been refined to make sure it's done in the optimal way? Did any of you with any level of degree in Computer Science learn any of that — other than, of course, some boiler-plate about the virtues of object-oriented languages and maybe some other fashionable stuff? Of course not! Anyone with any sense of fashion and/or status knows that these are not career-advancing subjects. Anything involving software history or comparative study of software projects is career-killing.

    Conclusion

    Software evolves. But it evolves differently than other things studied by science. Virtually no one studies software history in any way, much less the patterns of evolution that become apparent when you study that history. There have been a couple of attempts to learn why software doesn't get better in the way many other things do, most notably Fred Brooks with his book The Mythical Man-Month and other writings. I have dissected this flawed analysis in my work on Software Project Management and Wartime Software. See this for a start.

    I have worked for years trying to identify some notable patterns in software evolution, and will be releasing some of that work in the coming months.

  • Software is a Pre-Scientific Discipline

    For a wide variety of human-understandable reasons, software is perceived as a science. In academia, it's taught in the Computer Science department, often part of the math department. What could be more precise and scientific than that?

    Whatever its pretensions, software is anything but scientific. It's mostly driven by fashions and fads, led by "experts" who promote theories that sound good when described — but which entirely lack any form of scientific process, testing or evidence.

    Software diseases will continue to severely hamper our computer systems until we wake from our long, pre-scientific sleep. We will know we're making progress when software practices at least to the level medicine had achieved 150 years ago. See these examples: the history of scurvy; the history of bloodletting; Yahoo and Hadoop.

    The Evolution of Science

    Science is not one thing, although the core principles of hypotheses, testing and evidence are always the same. Sciences don't pop up full-grown from nothing. Each field of human endeavor evolves towards being a science (or not) at its own time and pace. There is typically a long gestation period during which resistance is deep and widespread. Physics is a classic example.

    Even when an area of science is well-established, the temptation to simply declare and assert the truth of something without careful proof remains strong and happens all too often. Science is something that human beings do, so it's never "perfect." It's also never "done." The resistance of the entire physics establishment to the now-accepted fact that time changes as the speed of an object approaches the speed of light, and that light has no mass but nonetheless exists and travels at a measurable rate, are classic examples of the fits-and-starts evolution of even the well-established science of physics.

    It was a long, hard slog for medicine to emerge from its pre-scientific state. While there is loads of room for improvement, as I have often pointed out in this blog, medicine has clearly and explicitly embraced scientific discipline in the large majority of its practices, of course with the occasional embarrassing slippage.

    The non-evolution of software towards science

    Let's compare the emergence of powered flight as a science to the methods for building software projects. Here are the key points:

    • Powered flight was widely recognized as important more than 100 years ago. There were widely accepted experts, and the entire establishment gave them money and support. After a couple spectacular failures by the experts, the obscure people who actually figured out how to create a heavier-than-air flying machine got it done, and their methods were soon universally followed. Here is the story in more detail.
    • Building effective software is widely recognized as important today. There are widely accepted experts, whose methods are taught in schools, practiced in all major institutions and mandated by government regulations. After spectacular, repeated failures, everyone says "oh, that's software, what can you do," and moves on. Meanwhile, sometimes obscure people build amazing new software quickly and well most often using unauthorized methods. Their software is widely used and their companies acquired by the big organizations who can't build anything. Nothing changes. Here is an example and details.

    To take another example, while there are many ways that the science of medical drug development could be improved, there is little doubt that it is a scientific venture. In terms of science, in spite of its problems, limitations and inefficiencies, drug development is probably a hundred years ahead of "computer science" in general and software development in particular. See this for a comparison.

    If software were a science

    Think of a list of established principles in software — if software were in fact a science, the things that would be like the basic equations of non-relativistic motion. What's on the list? I suspect it includes things like: Object-oriented programming, comprehensive test automation, architecting for scalability.

    Now think of a list of hot new methods or techniques in software, things that are widely accepted but early in widespread adoption. The list may include, depending on the circles in which you travel, things like micro-services, the Clojure language, Agile methodology with SCRUM, test-driven development.

    Which of the items on either list — your version of the lists, not mine — went through anything like this process:

    There was a bad problem that accepted methods weren't solving. People hypothesized an underlying cause and/or a cure, tested it first on a small scale and then on a larger scale. The evidence was overwhelming in A:B comparison that the cure was effective, so it became accepted.

    Or,

    There were observations that didn't fit existing theories, data that wasn't explained, or discrepancies that couldn't be accounted for. Someone came up with a theory that made sense out of the rogue data. Others formulated the theory exactly and conducted careful experiments; the results were made public, and maybe there was a period of refinement. Finally, the new theory was accepted, because it was experimentally proven to account for all the measured data, something the old theory could not do.

    Anyone with reasonable software experience knows the answer to these simple questions: software doesn't work that way! Not even a little bit! Instead, new practices are invented, promoted and sometimes accepted into common practice. In no case is there a scientific vetting process! People just accept the theory because

    • it makes sense to them, or
    • it's what they've been taught, or
    • it's required by the mandated practice of the group in which they work
    • it somehow advances their career or enhances their prestige

    Sometimes, happily, software fads just fade away for as little reason as they started. A fairly recent example is pair programming, which I describe and examine here.

    In the face of this evidence you may swallow hard and admit that software may not be a science, but it is an established discipline with standards and processes that are widely accepted, as for example you can see in the FDA software regulations. Sadly, that makes it even worse, if it's possible to imagine that. The standards and processes that constitute modern software practice are taken from other fields and jammed onto software. They don't fit and they don't work.

    Conclusion

    No testing. No hypothesis with controlled experiment. No evidence. No process that resembles either medicine (we know there's a problem, we have a possible solution, let's prove it works before using it widely) or physics (we have this data we can't explain, let's propose a theory that accounts for it and run experiments that will prove it right or wrong) or anything else.

    You can say that building software is part of "computer science" until you're blue in the face. You can require CS degrees for your new hires. But the evidence is that software is, without question, pre-scientific.

    We need to at least start building towards a true Science of Software.

     

Links

Recent Posts

Categories