I'm afraid that I'm at a slight disadvantage, since I had duty this past weekend, plus worked today, and during the weekend when I was free the forum was down.
I have worked professionally as a software engineer for the past 27 years. Whenever you start a project, ... let's leave that situation until later.
It is relatively rare that you can start a completely new project from scratch. More often, you get assigned an existing project to maintain. This can be the case both when you have been working there for a while and when you are newly hired (in my five jobs since 1982, the first two were on new projects (the second one was design work before coded ever got started), and the other three were on existing projects).
Here's what happens when you maintain a project. You learn how the original design works. Then management wants you to add a new feature, so you need to add that new feature in a way that still agrees with how the application already works. Then another feature, and another. With each new feature, you take what's already there and you modify it to handle the new feature. It's an evolutionary process; an existing feature is modified or copied-and-modified to perform a new function, all while keeping all the previous functionality intact. It's kind of like a croc growing to the point where his three-chambered heart becomes a four-chambered heart ... without ever skipping a single heart-beat.
The result of such an evolutionary process of software development is ever-increasing complexity that approaches
irreducible complexity -- research in genetic algorithms have shown that irreducible complexity is an expected result of evolutionary processes. What that means for the software engineer is that the software becomes ever increasingly complex and gets to the point where any change you make, regardless of how small, could have disasterous effects on the application's operation -- that is why
regression testing is so vitally important, assuring that all other functions have not been adversely affected by the "fix".
OK, new project time. A new project presents itself. In most cases, this new project is very similar to existing projects, yet also quite different. The temptation is to take one of those similar existing products as the new project's baseline and just modify it slightly. The problem with that is that the baseline project brings in all its "irreducible complexity" baggage. The engineers' most highly desired approach is to jettison all that baggage and to start from scratch.
Cases in point. At my first job, towards the end (before the gov't cancelled the project), I was given two other programmers' applications to maintain. In those days (circa 1982-1985), the DOD had mandated the use of a new programming language, Ada (named for Ada Augusta, Lady Lovelace, the world's first computer programmer whose birth-year, 1815,was incorporated in the language standard's designation, MIL-STD-1815). Part of that mandate was the use of a validated compiler (a compiler that supported
all features of the language specification), which did not exist at that time. So aerospace contractors at that time were using the Pascal language, which kind of was the basis of the "Green Language" (the competition used colors to identify them; the Green Language won, so the MIL-STD-1815 document was bound in green). At my first civilian job, I was unique in two major ways: 1) I was a Computer Science major, 2) I came out of school with two years experience in Pascal.
In the case of the first programmer's code, she was experienced in FORTRAN, so she had coded all the repetitive actions by placing that code in-line every time it was used, rather than following the
structured programming approach of turning that repetitive code into a function and then calling that function. Her code was easy to convert over to the Pascal way of thinking.
The other programmer's code was much more of a problem. His experience was in assembly language. And he had decades more experience than either of us had. His approach was to have one main loop and several flags (BOOLEAN variables), the TRUE/FALSE values of which would determine what actions would be taken during each pass through the main loop. His code was my first exposure to irreducible complexity, and I was supposed to make changes to it! One thing I learned in the Air Force was that you never want to come to your supervisor with a problem; rather, you want to come to him with solutions to that problem. So I took that pseudo-assembly code and translated to Pascal-like structured code. Then I approached my supervisor with the problem and was able to show him that the converted code I had created from it did the same thing as the original code. Thus I was able to do something that I have never ever since then been able to do: completely rewrite unmaintainable code. That almost never ever happens.
Engineers almost never have any say as to what design approach they will make. That is because such a decision is almost never an engineering decision, but rather an economic one. In the project I currently work with (ignoring that there are more than 20 versions of it), consists of more than 100 source files and could easily consist of 100,000 lines of code or more (lines-of-code is a largely obsolete metric, more amenable to FORTRAN than to C). It takes time to develop each line of code,
and to test it. If you were to start each project from scratch, then the time and work it would take would be prohibitively expensive, plus the code you would have generated would be untested and probably full of bugs. So the safer approach is to keep the things that are the same (and already proven) and just change the parts of the code that need to be changed.
And that is the approach that
management dictates. Even when starting a new project from scratch would be the better way, the cost of that approach would be too prohibitive to take. Like that croc transitioning from a 3-chambered heart to a 4-chambered, a company needs to stay alive throughout any transition -- eg, possibly, Kaypro was one of the premier CP/M microcomputers and they announced their next model, the KayPro II, that would obsolete their first model, but then they ran into development delays and ended up going out of business because everybody was waiting for the KayPro II and wouldn't buy a KayPro I. What company can afford the massive expense of developing
from scratch the next generation of an existing product? Know why new drugs are so expensive? Because they have to
amortize the development expense; ie, the expense of developing the product needs to be recuperated, so it gets factored in the the product's price. Otherwise, the company takes a loss and goes out of business -- or at the very least will never have any reason to do R&D.
OK, there are some truths about the
human design process and the economics involved. How do they translate of an omni-present, omni-potent Creator?
Reusing previous designs is a human thing. But a "godly" thing? Human fallibility dictates that designing from scratch is necessary, but an omni-potent god is not limited in such a manner -- it's too much work for too much time with too many bugs introduced for
mere humans, but not for
God. Economic concerns absolutely dictate the route that engineers will take, practically forcing them into the evolutionary tract. What
omni-potent God could
ever be
forced into such a course of action? IOW,
God could not possibly be forced into the design restraints that mere human engineers must constantly contend with.
So what do we see in the natural world? Can "God" do His designs any damned way He pleases? Or are His designs always constrained by evolutionary processes?
It is always the latter case.
PS
Just to make the conclusion more clear.
We humans reuse and modify previous designs because of our limitations. An omnipotent god would not have any such limitations.
Human engineers are constrained very greatly by economic concerns, such as the need to greatly shorten the design time and effort and cost. An omnipotent god would not have any such concerns or constraints.
Many times engineers would prefer to start from scratch rather than to wrestle with an existing design that has grown overly complex to the point of approaching irreducible complexity, but their bosses make that decision and engineers must obey their bosses. Who would be the boss over an omnipotent god?
Sometimes, even the bosses agree to allow their engineers to start from scratch. Or to replace major portions of an existing design with an entirely different design. Or even to merge together two entirely different designs. Of course, an omnipotent god could do that anytime and at will. An omnipotent god could even perform a major overhaul without any concern for keeping the affected lifeform viable throughout the entire process.
So while there are many constraints placed on human designers, there are no conceivable constraints that could be placed on any omnipotent supernatural designer. So why do we not only see constraints having been placed on nature, but we see far greater constraints being placed on nature than even human designers have to work with? While designers of any stripe, human or divine, can make arbitrary decisions in the design and can replace major sections at any point of the design, there is nothing arbitrary in what we find in nature, nor any changes that didn't arise from the previous versions of the design. And while designers of any stripe, human or divine, can go back in and clean up the design, removing old unused portions (eg, we frequently go back and delete old code that had been commented out), we continually find old unused designs in nature (eg, genes in birds for teeth).
Edited by dwise1, : PS
™ Version 4.2
(1)
