4 ms·

I prefer the term `software gardener' to `software engineer' for this reason: software is slowly created over time and requires constant care, or it will wilt a

I prefer the term `software gardener' to `software engineer' for this reason: software is slowly created over time and requires constant care, or it will wilt and die.

TeMPOraL 12y ago
I never liked this analogy. There is no such thing as software entropy - bits are bits, and the code doesn't decay with time. The only reason we have maintenance problems is because we keep changing components. If you program a box, unplug it from the Internet and leave it running, the code will continue to work until the hardware physically fails. Programming for the on-line world is more like managing a clothing brand - everything is constantly changing around you, things go out of fashion every other month and you need to keep up or else your brand will die and get quickly forgotten.
- wcummings 12y ago
  >everything is constantly changing around you Like an ecosystem? ;)
  - TeMPOraL 12y ago
    Well, ok. I guess my point is that programming is like gardening only if you deliberately decide to work in an environment that forces you to keep up with changes, like the Internet. Software for infrastructure can easily last unchanged for 20+ years.
    - saalweachter 12y ago
      I really like the ecosystem analogy. Ecosystems have a variety of niches which change at varying paces. A shark isn't better than a finch because it is more stable on the evolutionary timescale, it is well-adapted to a stable niche. More stable niches are not better or worse than transient, quickly-changing niches, they're just more stable. I think it is important to recognize that the stability of a niche is independent of its value or the care that should be taken filling it. A feed processor must be written carefully even though most often they only live a couple of years before the underlying need for it goes away. A compiler is of great value but without constant maintenance it will be worthless within a few years, as compiler techniques evolve, languages are restandardized, and machine architectures shift. Software written as part of scientific inquiry is frequently worthless and uninteresting after the questions being examined have been answered.
- r00fus 12y ago
  So where do security updates factor into your diatribe? You're saying bits don't decay, but to be honest it's not bits you're coding, it's logic. When underlying shared libraries and OS gets update because of security updates, your code ages a bit. In a while it won't behave as you expect, and after long enough it simply won't work. And let's face it - I would bet less than 1% of the people in this forum write code they would expect to reside in an unconnected box. As soon as you connect it, security updates are required/happen.
  - icebraining 12y ago
    TeMPOraL's post was hardly a diatribe.
- steveklabnik 12y ago
  > There is no such thing as software entropy - bits are bits, and the code doesn't decay with time. The article contains some thought that disagrees: > To program any more was pointless. My programs would never live as long > as [Kafka’s] The Trial. A computer will never live as long as The Trial. > … What if Amerika was only written for 32-bit Power PC? Can an unfinished > program be reconstructed? Can I write a program and go, “Ah, well, you > get the gist of it.” … But no. It wasn’t written for 32-bit Power PC. It > was written for eyes. See, The Trial was written on a platform that's been around quite a while: German. And it was ported to other, fairly stable platforms, like English. However, if you write some code from the 32-bit PPC architecture, the vast majority of 'readers' possible for your code is very, very small. And dwindling by the day. Nothing you can do! Other than keep working on the code, porting it to the latest version of the OS, architecture, platform, API version, or whatever.
  - tormeh 12y ago
    You can write it in C. Bloody thing is like a particularly disgusting cockroach. I bet people can still read it in way too many years, to the extent that C can be read.
    - steveklabnik 12y ago
      Even in C, it's not insta-portable. In the quote author's case, the UI framework was entirely deprecated, basically requiring a large re-write to use the new API, to keep the same functionality. If you wrote some C code that ran on Mac OS 9, for example, you'd eventually be forced to upgrade, because eventually, there are no computers running OS 9 anymore.
      - derefr 12y ago
        Gary Bernhardt's "The Birth and Death of Javascript"[1] is a rebuttal to this, I think. Effectively, imagine that a compiler, put in static-compilation mode, would link everything required to run a piece of code (the relevant windowing toolkit, all the system libraries, copies of any OS binaries the code spawns, copies of any OS binaries the code sends messages to over an IPC bus, etc.) into something resembling a Docker container, or a Unikernel VM image. Imagine, additionally, that all this then gets translated into some standard bytecode for a high-level abstract platform target that has things like graphics and networking primitives—say, asm.js. Now everything can live as long as something still executes that bytecode. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- amalcon 12y ago
  Exactly. When was the last time you had to update the firmware on your microwave?
  - bostonvaulter2 12y ago
    That's because it doesn't need to integrate with anything yet. Most software written now does need to integrate with many different things, especially obvious on web and mobile.
Retra 12y ago
We live in such a primitive era of programming that you shouldn't compare it to printed books, but to scrubbed reusable parchment. We don't write good enough code to last. We don't have robust enough machines to keep it in service. It's too soon to adopt a philosophical position on what it means to write code. We don't do it well enough to claim to be experts at it.
- derefr 12y ago
  One might rebut that with an analogy to the William Gibson quote: quality programming is already here—it's just not very evenly distributed. We write code that lasts all the time. We call it "embedded code." Satellites, nuclear power plants, microwaves, pacemakers, cars—they all run code that lasts. Most code doesn't last, because most code doesn't need to last. It's not part of the profit-function of the business producing the code, so something else gets optimized for: ease and speed of production, say. We can code well when there's any sort of incentive to that outweighs other incentives. It's not even a matter of individual programmer skill, only of systems engineering: having checks and cross-checks, QA reviews and burn-in testing, tolerances, etc. Those things can happen "in the small" at the level of how individual lines of code get written, too. Maybe "we" don't know how to do that. But that's ignorance, not inability. We've never tried.
  - Retra 12y ago
    That's quality programming by today's standards. And you say it lasts, but there probably isn't a single piece of code that has lasted a full century. That's barely more than a single lifetime. Comparing microwave code to the code I'm talking about is like comparing medieval accounting records to Hamlet. One is far more impressive than the other.
pjmlp 12y ago
Would that be an university degree? On my world software engineer is a synonym for what is known as CS degree. So I can only expect it to be comparable, if gardening would be one as well.

I prefer the term `software gardener' to `software engineer' for this reason: software is slowly created over time and requires constant care, or it will wilt and die.

TeMPOraL 12y ago

I never liked this analogy. There is no such thing as software entropy - bits are bits, and the code doesn't decay with time. The only reason we have maintenance problems is because we keep changing components. If you program a box, unplug it from the Internet and leave it running, the code will continue to work until the hardware physically fails. Programming for the on-line world is more like managing a clothing brand - everything is constantly changing around you, things go out of fashion every other month and you need to keep up or else your brand will die and get quickly forgotten.

wcummings 12y ago
>everything is constantly changing around you Like an ecosystem? ;)
- TeMPOraL 12y ago
  Well, ok. I guess my point is that programming is like gardening only if you deliberately decide to work in an environment that forces you to keep up with changes, like the Internet. Software for infrastructure can easily last unchanged for 20+ years.
  - saalweachter 12y ago
    I really like the ecosystem analogy. Ecosystems have a variety of niches which change at varying paces. A shark isn't better than a finch because it is more stable on the evolutionary timescale, it is well-adapted to a stable niche. More stable niches are not better or worse than transient, quickly-changing niches, they're just more stable. I think it is important to recognize that the stability of a niche is independent of its value or the care that should be taken filling it. A feed processor must be written carefully even though most often they only live a couple of years before the underlying need for it goes away. A compiler is of great value but without constant maintenance it will be worthless within a few years, as compiler techniques evolve, languages are restandardized, and machine architectures shift. Software written as part of scientific inquiry is frequently worthless and uninteresting after the questions being examined have been answered.
r00fus 12y ago
So where do security updates factor into your diatribe? You're saying bits don't decay, but to be honest it's not bits you're coding, it's logic. When underlying shared libraries and OS gets update because of security updates, your code ages a bit. In a while it won't behave as you expect, and after long enough it simply won't work. And let's face it - I would bet less than 1% of the people in this forum write code they would expect to reside in an unconnected box. As soon as you connect it, security updates are required/happen.
- icebraining 12y ago
  TeMPOraL's post was hardly a diatribe.
steveklabnik 12y ago
> There is no such thing as software entropy - bits are bits, and the code doesn't decay with time. The article contains some thought that disagrees: > To program any more was pointless. My programs would never live as long > as [Kafka’s] The Trial. A computer will never live as long as The Trial. > … What if Amerika was only written for 32-bit Power PC? Can an unfinished > program be reconstructed? Can I write a program and go, “Ah, well, you > get the gist of it.” … But no. It wasn’t written for 32-bit Power PC. It > was written for eyes. See, The Trial was written on a platform that's been around quite a while: German. And it was ported to other, fairly stable platforms, like English. However, if you write some code from the 32-bit PPC architecture, the vast majority of 'readers' possible for your code is very, very small. And dwindling by the day. Nothing you can do! Other than keep working on the code, porting it to the latest version of the OS, architecture, platform, API version, or whatever.
- tormeh 12y ago
  You can write it in C. Bloody thing is like a particularly disgusting cockroach. I bet people can still read it in way too many years, to the extent that C can be read.
  - steveklabnik 12y ago
    Even in C, it's not insta-portable. In the quote author's case, the UI framework was entirely deprecated, basically requiring a large re-write to use the new API, to keep the same functionality. If you wrote some C code that ran on Mac OS 9, for example, you'd eventually be forced to upgrade, because eventually, there are no computers running OS 9 anymore.
    - derefr 12y ago
      Gary Bernhardt's "The Birth and Death of Javascript"[1] is a rebuttal to this, I think. Effectively, imagine that a compiler, put in static-compilation mode, would link everything required to run a piece of code (the relevant windowing toolkit, all the system libraries, copies of any OS binaries the code spawns, copies of any OS binaries the code sends messages to over an IPC bus, etc.) into something resembling a Docker container, or a Unikernel VM image. Imagine, additionally, that all this then gets translated into some standard bytecode for a high-level abstract platform target that has things like graphics and networking primitives—say, asm.js. Now everything can live as long as something still executes that bytecode. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
amalcon 12y ago
Exactly. When was the last time you had to update the firmware on your microwave?
- bostonvaulter2 12y ago
  That's because it doesn't need to integrate with anything yet. Most software written now does need to integrate with many different things, especially obvious on web and mobile.

Retra 12y ago

We live in such a primitive era of programming that you shouldn't compare it to printed books, but to scrubbed reusable parchment. We don't write good enough code to last. We don't have robust enough machines to keep it in service. It's too soon to adopt a philosophical position on what it means to write code. We don't do it well enough to claim to be experts at it.

derefr 12y ago
One might rebut that with an analogy to the William Gibson quote: quality programming is already here—it's just not very evenly distributed. We write code that lasts all the time. We call it "embedded code." Satellites, nuclear power plants, microwaves, pacemakers, cars—they all run code that lasts. Most code doesn't last, because most code doesn't need to last. It's not part of the profit-function of the business producing the code, so something else gets optimized for: ease and speed of production, say. We can code well when there's any sort of incentive to that outweighs other incentives. It's not even a matter of individual programmer skill, only of systems engineering: having checks and cross-checks, QA reviews and burn-in testing, tolerances, etc. Those things can happen "in the small" at the level of how individual lines of code get written, too. Maybe "we" don't know how to do that. But that's ignorance, not inability. We've never tried.
- Retra 12y ago
  That's quality programming by today's standards. And you say it lasts, but there probably isn't a single piece of code that has lasted a full century. That's barely more than a single lifetime. Comparing microwave code to the code I'm talking about is like comparing medieval accounting records to Hamlet. One is far more impressive than the other.

pjmlp 12y ago

Would that be an university degree? On my world software engineer is a synonym for what is known as CS degree. So I can only expect it to be comparable, if gardening would be one as well.