in reply to Re^10: "Practices and Principles" to death
in thread "Practices and Principles" to death

An initial point - the source code is the blueprint. The functioning of the source code is the building. Customers don't pay for code, they pay for functionality.

The distinction missing here is the relative ages of the two professions under consideration. Software engineering, as a profession, is no more than 60 years old (and I'm being generous). Architure, as a profession, is at least 6000 years old. That's a factor of 100. Instead of 3 generations, we're talking 300 generations. This means that, barring really weird concepts, every building under consideration has already been built before. You can point to a building that the customer can go touch which has the characteristics being discussed AND the architect can go look at the blueprints of said building. While there are hundreds upon hundreds of application requests on codelance (and the like) saying "I want to build something that looks just like XYZ", no-one can go look at the blueprint for Word or Windows or eHarmony in order to learn from it.

The only place this kind of information exchange exists is in the OSS world. That, and that alone, is why OSS is so important. It makes coding into something approaching architecture.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^11: "Practices and Principles" to death

Replies are listed 'Best First'.
Re^12: "Practices and Principles" to death
by chromatic (Archbishop) on Mar 05, 2008 at 02:37 UTC
    The distinction missing here is the relative ages of the two professions under consideration.

    That's one distinction. Another distinction is that software is a virtual product, not even patterns of electricity. If there's a manufacturing step at all, it's running the software through the compiler.

      The entire manufacturing process for software is in producing the blueprint. We're not engineers, we're architects. Or, at the very least, blueprint artists.

      Pretty soon, we'll be building houses the same way, using 3-D fabbers. That'll be really cool. Screw up the program? Rip it down and start over. If the right materials are used, you could even recycle that. The only costs are energy and time.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?