7 ms·

I've come to the conclusion that code is temporary, and is meant to be discarded after a while. Hardware change, requirements change, people change. The things

I've come to the conclusion that code is temporary, and is meant to be discarded after a while. Hardware change, requirements change, people change. The things that are permanent are data and methods. That's why I think as long as you have documented and defined your methods (i.e. business logic) well, and your data is portable, you shouldn't worry much about vendor lock-in in the long run.

Edmond 6y ago
Agreed. The primary reason the software development field has evolved to be preoccupied with saving/re-using/inter-op code is because of the difficulty of building even the most trivial piece of software. Unfortunately code hoarding is simply a reflection of the age-old human flaw of wanting to recoup sunk cost, you assume if you've invested a lot of time into something, it must be worth holding on to for as long as possible :) If software was as easy to make as a piece of office stationary is easy to write on, no one would care about code reuse/saving/interop...you don't see anyone saving post-it notes or even excel docs for indefinite reuse.
- wintorez 6y ago
  I couldn't agree more. A personal anecdote; I used to think about what would be my legacy as software developer? Anything that I write would be obsolete in few years. Nothing I wrote back then remained working. This thought was depressing me. Then I realized that what I'm actually creating and maintaining is not code. It's the mindset behind the code, and the skillset to convert ideas to working pieces of software. My legacy would be to learn through experimenting, and to help others learn the same.
  - bonoboTP 6y ago
    Who has a legacy anyway and why would a normal person expect to have one? A tailor's clothes get worn out, a farmer's food is eaten, the cook's dish eaten, the hotel cleaner's "output" gets messy again, the architect's apartment block torn down etc. Who has a true legacy outside a small minority of philosophers, artists, scientists and political leaders?
    - wintorez 6y ago
      I think even the idea of having a tombstone is a sort of legacy. People made cave-paintings to leave something behind. We all want to cling to existence somehow and want to leave a mark on world when we leave. The simplest way maybe is to have children, so your gene would live on after you.
      - mathgeek 6y ago
        > We all want to cling to existence somehow and want to leave a mark on the world when we leave. Not everyone wishes to leave a mark on the world after we are gone. There are entire philosophical branches dedicated to the idea of embracing mortality and accepting that which makes us human.
        antepodius 6y ago
        I feel like that's just a way to cope with the horror of death.
        mathgeek 6y ago
        Naturally, but it's also a way to approach death if you don't consider it a horror.
        dwaltrip 6y ago
        One can embrace mortality while also wishing to leave a positive mark on the world.
      - AstralStorm 6y ago
        Most of the paintings get lost, even sometimes masterpieces. Bloodlines die out or change enough to not be recognizable.
- feoren 6y ago
  I see Excel documents that have been reused hundreds of times for dozens of different purposes over the last 20 years. I see that all the time. "Too many styles", VBA macros from the 90s, hundreds of items in the Name manager that refer to long-forgotten hard drives or #REF!. It's everywhere.
core-questions 6y ago
> you have documented and defined your methods (i.e. business logic) well Wishful thinking, though, in many cases. When software dictates the workflow, the code _is_ the business process documentation. Add a new function to the code? Did you go and update the docs, too? Takes serious diligence, takes bigger teams, hard for a small business systems department to keep up with that. That's why they use low-code platforms, aside from the skill gap (i.e. once you can really code, you tend to not want to write business systems stuff anymore)
- Dudeman112 6y ago
  What do you tend to want to write once you can really code?
rufus_foreman 6y ago
As Tom Kyte said: "I take the view that applications come. Applications go. Applications come again and go again. But - the data, the data - oh, it stays and stays and stays and is used by application after application after application. And if you store your data perfectly for "the first application", it'll not be good for the future ones. And I don't see tons of data that isn't used by many applications (need many views of the same data). See, my goal is the data - knowing that applications are like Mayflies but data is more like a tree."
teddyh 6y ago
> you shouldn't worry much about vendor lock-in in the long run. You should always worry about vendor lock-in. Vendors only do it because they gain something by it, namely reduced competition. Reduced competition is always bad for the consumer.
- cle 6y ago
  Not necessarily, and vendors don’t only do it to reduce competition, and not all vendors do it either. As a consumer, having 50 nearly-similar options to choose from is arguably worse than having only a few. With 50 choices you’ll get an entire sub industry devoted to “helping” you make a choice, and you’ll likely miss out on certain economies of scale. As a vendor, it’s a lot easier to understand, support, and build products for your customers if they are only using your products. There are obviously negatives to vendor lock-in, but framing it as entirely negative is misleading.
  - msla 6y ago
    Indeed: Ideally, there would be one car. Ford. Ford would be the only vendor for cars, and Ford would be the only car vendor. We'd have the technology approved by Ford and all of the technology approved by Ford, including black paint, carburetors, tetraethyl lead, and, through a special deal with Radio (formerly RCA), AM radios tuned to Radio, the only Radio company and station in the world. These vehicles would be simple to maintain, in that the only maintenance option is to ship them to Ford, and simple to customize, in that you cannot. And anyone who attempts to modify their Ford would be subject to legal penalties, up to and including bomb-making, just as if they'd tried to destroy any other institution.
    - cle 6y ago
      Wow, that's not at all what I'm saying. Did you notice how I offered no prescriptive nor normative statements? I'm just observing that there are tradeoffs involved--there are some beneficial properties that emerge as the number of choices decrease (along with a bunch of detrimental ones). Pretending like those don't exist does nobody any favors. Since you asked, my opinion is that there's a healthy tension between too many choices and not enough choices, and we should strive to maintain that tension. Which requires an objective understanding of the tradeoffs, instead of knee-jerk reactions to the phrase "vendor lock-in".
rvense 6y ago
> I've come to the conclusion that code is temporary, and is meant to be discarded after a while Interesting, my gut feeling is the opposite. I think code is being written today that will remain running for something approximating "forever". Stuff will work and people won't want to change it - or things will be so intermingled that they won't dare to.
- corytheboyd 6y ago
  Out of curiosity what is the context behind the code you think will have a long lifetime? As someone who works on “webcrap” as they say, I don’t think anything I contribute to will work for more than a few years.
  - AnthonyMouse 6y ago
    The code for a lot of the standard Unix utilities was written decades ago. They'll modify the code when there is a reason to, but often there isn't.
  - rvense 6y ago
    If a business lives for a long time, even its "webcrap" might live with it. Honestly I think the investments made into web technology right now are so massive and pervasive that I wouldn't be surprised if we still use something that looks a lot like the web stack in 50 years, simply because there'll never be a good moment to dump all that baggage when you're so deep in it. I don't think we can look to the past of computing to understand its future, I think we have reached in the past ten years or so a critical mass and penetration into the fabric of society that the rules are just different know than they were in the 90's. Unless the way we interact with our computing devices fundamentally changes (say, a shift from visual/touch to, idk, voice or brain waves or whatever), I have a hard time seeing how there'd ever be a big shift from the web stack to something else like, say, the shift from Win32 apps to web apps. Hell, even if there is, the web might just embrace it. My day job is web-based AR... The stack will evolve, sure, and maybe at the end there's nothing left and the clients won't know HTTP at all anymore... but I can just as easily see us just piling more stuff on, because I honestly think that, even with voice assistants and AI and whatever, most people are still going to produce and consume text and images from a device a lot like a phone for many years to come, simply because it's a system that works well for humans that have eyes and fingers and pockets. And if that's the case, then what's going to cause a seismic shift in platforms, when almost all software developers are web developers, and all devices run web applications? And if the stack doesn't change, why wouldn't some of the code stick around, if the business or organization that invested in it does? Some businesses now might replace twenty-year-old code just because, but at least part of that is because of how software stacks have changed and aged, and I think the sheer amount of "webcrap" that's being excreted by people like you and me is going to slow that rate of change right down, even if it doesn't feel like that in the middle of all the framework churn.
dustingetz 6y ago
Big data is permanently in AWS
- goatinaboat 6y ago
  Big data is permanently in AWS Egress costs make sure of that!
- wintorez 6y ago
  Asking this out of my ignorance, but there're no ways of exporting and extracting big data out of AWS?
  - freedomben 6y ago
    There's definitely ways, and it isn't hard, but AWS charging heavily for egress data. I've had bills with AWS that were $200 a month, where $160 of that was egress charges.
- WJW 6y ago
  As long as you keep paying, of course.
goatinaboat 6y ago
That's why I think as long as you have documented and defined your methods (i.e. business logic) well, and your data is portable, you shouldn't worry much about vendor lock-in in the long run. That's a huge big IF. In many if not most cases the only reliable documentation of a system is the running code itself.
Ma8ee 6y ago
In most cases, the only reliable documentation and definition is the code itself. It's is rare for most of us where it is hard to figure out how to do something. In general the only hard part is to figure out exactly what needs to be done.
- sltEvas 6y ago
  Actually, code isn't what does that. It's true that code is one of the things that keeps it "all". However, it's not the best place for documentation or even storage of that knowledge. Code changes. Tests are what you need to invest in. When you test all of you business use cases in an abstract (perhaps even no-code) way, you are truly independent. You can rewrite the system very quickly, if you had a test-suite that allows for quick iteration (TDD style) and does not depend on implementation details. Given just the code? Well good luck migrating to another cloud vendor. You will probably introduce one million bugs on the way.
  - ironSkillet 6y ago
    What are some techniques you use to test business use cases in a code independent way?
    - loopz 6y ago
      You'll want to test against stable API/ABI, and use positive and negative testcases. The problematic parts are mocking, simulation and how tests affect the codebase.
      - redis_mlc 6y ago
        > You'll want to test against stable API/ABI Good luck with that. lol. - The only stable APIs I've seen, if an API exists, are production financial APIs, because money is involved. - DynDNS has been knows to change input and output parameter types, breaking calls - Even Twilio has changed a fundamental API path (!) in the past couple of years, breaking SMS API calls in 2019 - Facebook only supports API version N and N-1. Hope you're not on N-2 and there's a sudden version bump! (I say production APIs, since even payment gateways often have flaky dev/qa gateways that you can't reliably do automated tests against. Past companies that I worked at had to test against prod gateways with their own personal credit cards.) Otherwise, if you want an API, ensure you choose a product/partner that offers/supports one.
m463 6y ago
Taking the 10,000 foot view that "code is temporary"... I think "business logic" is indeed temporary. With very few exceptions, most code you write for someone else will not stand the test of time. In fact, most of the companies I've worked for do not exist or have greatly changed over the years. MIT/BSD software is a little better. And strangely - GPL software does stand the test of time.
- wintorez 6y ago
  I think my usage of the term "business logic" was a bit misleading. What I meant was more the methods and ways which we expect the data to be processed; more like requirements than anything.
- nyanpasu64 6y ago
  Is it because MIT/BSD software is more common in web or scripting language cultures, where code tends to be replaced faster? Or more common in newer code which most will not survive for years?
  - AnthonyMouse 6y ago
    MIT/BSD licenses allow for proprietary forks. The most popular BSD-based kernel is Apple's, which isn't distributed under the BSD license. The most popular GPL kernel is Linux, which still is. So with the BSD license somebody can take your work, improve it, distribute it under a proprietary license and supplant you in the market. Compare macOS or iOS installed base to FreeBSD. But then the codebase is henceforth tied to that company. If Apple is dead in twenty years then probably nobody is still using the iOS kernel (and not because they switched back to FreeBSD), but if Google is dead in twenty years most likely Linux is still popular all over.
    - 67868018 6y ago
      MacOS/iOS is not based on a BSD kernel. https://imgpile.com/images/uL3CFP.jpg https://imgpile.com/images/uL3CFP.jpg
pachico 6y ago
Not only that. Good code should be easy to throw away without major effort.
- wintorez 6y ago
  For me, writing code has became like making a sandcastle. I sure put a lot of time and effort in it, but I never try to preserve it. It's pointless. What I preserve is the lessons I learned while building it, and applying them to build a better sandcastle next time.
monkeydust 6y ago
The only thing that remains from code are the real world decisons and actions that come from it
deleted 6y ago
[deleted]
drewcoo 6y ago
The article presented evidence for the primacy of humans. That things are sticky because they are built for humans. Your counterclaim to this piece is that humans aren't a thing that matters. Do you have reasons?
durandal1 6y ago
Pick "boring" and battle-tested solutions and this fades. I implemented a fairly complex kickback-tracking business system 15 years ago, due to the rest of the company being entry-level PHP devs, I implemented the whole thing in pl/pgsql. 15 years later it's still ticking as the core of the business with minor modifications. And the crazy thing is, in today's world of microservices and hyperfocus on horizontal scaling, I would still implement it in pl/pgsql, and indeed, I'd expect it to keep ticking for the next 20 years as long as the company stays in business.

Edmond 6y ago

Agreed. The primary reason the software development field has evolved to be preoccupied with saving/re-using/inter-op code is because of the difficulty of building even the most trivial piece of software. Unfortunately code hoarding is simply a reflection of the age-old human flaw of wanting to recoup sunk cost, you assume if you've invested a lot of time into something, it must be worth holding on to for as long as possible :) If software was as easy to make as a piece of office stationary is easy to write on, no one would care about code reuse/saving/interop...you don't see anyone saving post-it notes or even excel docs for indefinite reuse.

wintorez 6y ago
I couldn't agree more. A personal anecdote; I used to think about what would be my legacy as software developer? Anything that I write would be obsolete in few years. Nothing I wrote back then remained working. This thought was depressing me. Then I realized that what I'm actually creating and maintaining is not code. It's the mindset behind the code, and the skillset to convert ideas to working pieces of software. My legacy would be to learn through experimenting, and to help others learn the same.
- bonoboTP 6y ago
  Who has a legacy anyway and why would a normal person expect to have one? A tailor's clothes get worn out, a farmer's food is eaten, the cook's dish eaten, the hotel cleaner's "output" gets messy again, the architect's apartment block torn down etc. Who has a true legacy outside a small minority of philosophers, artists, scientists and political leaders?
  - wintorez 6y ago
    I think even the idea of having a tombstone is a sort of legacy. People made cave-paintings to leave something behind. We all want to cling to existence somehow and want to leave a mark on world when we leave. The simplest way maybe is to have children, so your gene would live on after you.
    - mathgeek 6y ago
      > We all want to cling to existence somehow and want to leave a mark on the world when we leave. Not everyone wishes to leave a mark on the world after we are gone. There are entire philosophical branches dedicated to the idea of embracing mortality and accepting that which makes us human.
      - antepodius 6y ago
        I feel like that's just a way to cope with the horror of death.
        mathgeek 6y ago
        Naturally, but it's also a way to approach death if you don't consider it a horror.
      - dwaltrip 6y ago
        One can embrace mortality while also wishing to leave a positive mark on the world.
    - AstralStorm 6y ago
      Most of the paintings get lost, even sometimes masterpieces. Bloodlines die out or change enough to not be recognizable.
feoren 6y ago
I see Excel documents that have been reused hundreds of times for dozens of different purposes over the last 20 years. I see that all the time. "Too many styles", VBA macros from the 90s, hundreds of items in the Name manager that refer to long-forgotten hard drives or #REF!. It's everywhere.

core-questions 6y ago

> you have documented and defined your methods (i.e. business logic) well Wishful thinking, though, in many cases. When software dictates the workflow, the code _is_ the business process documentation. Add a new function to the code? Did you go and update the docs, too? Takes serious diligence, takes bigger teams, hard for a small business systems department to keep up with that. That's why they use low-code platforms, aside from the skill gap (i.e. once you can really code, you tend to not want to write business systems stuff anymore)

Dudeman112 6y ago
What do you tend to want to write once you can really code?

rufus_foreman 6y ago

As Tom Kyte said: "I take the view that applications come. Applications go. Applications come again and go again. But - the data, the data - oh, it stays and stays and stays and is used by application after application after application. And if you store your data perfectly for "the first application", it'll not be good for the future ones. And I don't see tons of data that isn't used by many applications (need many views of the same data). See, my goal is the data - knowing that applications are like Mayflies but data is more like a tree."

teddyh 6y ago

> you shouldn't worry much about vendor lock-in in the long run. You should always worry about vendor lock-in. Vendors only do it because they gain something by it, namely reduced competition. Reduced competition is always bad for the consumer.

cle 6y ago
Not necessarily, and vendors don’t only do it to reduce competition, and not all vendors do it either. As a consumer, having 50 nearly-similar options to choose from is arguably worse than having only a few. With 50 choices you’ll get an entire sub industry devoted to “helping” you make a choice, and you’ll likely miss out on certain economies of scale. As a vendor, it’s a lot easier to understand, support, and build products for your customers if they are only using your products. There are obviously negatives to vendor lock-in, but framing it as entirely negative is misleading.
- msla 6y ago
  Indeed: Ideally, there would be one car. Ford. Ford would be the only vendor for cars, and Ford would be the only car vendor. We'd have the technology approved by Ford and all of the technology approved by Ford, including black paint, carburetors, tetraethyl lead, and, through a special deal with Radio (formerly RCA), AM radios tuned to Radio, the only Radio company and station in the world. These vehicles would be simple to maintain, in that the only maintenance option is to ship them to Ford, and simple to customize, in that you cannot. And anyone who attempts to modify their Ford would be subject to legal penalties, up to and including bomb-making, just as if they'd tried to destroy any other institution.
  - cle 6y ago
    Wow, that's not at all what I'm saying. Did you notice how I offered no prescriptive nor normative statements? I'm just observing that there are tradeoffs involved--there are some beneficial properties that emerge as the number of choices decrease (along with a bunch of detrimental ones). Pretending like those don't exist does nobody any favors. Since you asked, my opinion is that there's a healthy tension between too many choices and not enough choices, and we should strive to maintain that tension. Which requires an objective understanding of the tradeoffs, instead of knee-jerk reactions to the phrase "vendor lock-in".

rvense 6y ago

> I've come to the conclusion that code is temporary, and is meant to be discarded after a while Interesting, my gut feeling is the opposite. I think code is being written today that will remain running for something approximating "forever". Stuff will work and people won't want to change it - or things will be so intermingled that they won't dare to.

corytheboyd 6y ago
Out of curiosity what is the context behind the code you think will have a long lifetime? As someone who works on “webcrap” as they say, I don’t think anything I contribute to will work for more than a few years.
- AnthonyMouse 6y ago
  The code for a lot of the standard Unix utilities was written decades ago. They'll modify the code when there is a reason to, but often there isn't.
- rvense 6y ago
  If a business lives for a long time, even its "webcrap" might live with it. Honestly I think the investments made into web technology right now are so massive and pervasive that I wouldn't be surprised if we still use something that looks a lot like the web stack in 50 years, simply because there'll never be a good moment to dump all that baggage when you're so deep in it. I don't think we can look to the past of computing to understand its future, I think we have reached in the past ten years or so a critical mass and penetration into the fabric of society that the rules are just different know than they were in the 90's. Unless the way we interact with our computing devices fundamentally changes (say, a shift from visual/touch to, idk, voice or brain waves or whatever), I have a hard time seeing how there'd ever be a big shift from the web stack to something else like, say, the shift from Win32 apps to web apps. Hell, even if there is, the web might just embrace it. My day job is web-based AR... The stack will evolve, sure, and maybe at the end there's nothing left and the clients won't know HTTP at all anymore... but I can just as easily see us just piling more stuff on, because I honestly think that, even with voice assistants and AI and whatever, most people are still going to produce and consume text and images from a device a lot like a phone for many years to come, simply because it's a system that works well for humans that have eyes and fingers and pockets. And if that's the case, then what's going to cause a seismic shift in platforms, when almost all software developers are web developers, and all devices run web applications? And if the stack doesn't change, why wouldn't some of the code stick around, if the business or organization that invested in it does? Some businesses now might replace twenty-year-old code just because, but at least part of that is because of how software stacks have changed and aged, and I think the sheer amount of "webcrap" that's being excreted by people like you and me is going to slow that rate of change right down, even if it doesn't feel like that in the middle of all the framework churn.

dustingetz 6y ago

Big data is permanently in AWS

goatinaboat 6y ago
Big data is permanently in AWS Egress costs make sure of that!
wintorez 6y ago
Asking this out of my ignorance, but there're no ways of exporting and extracting big data out of AWS?
- freedomben 6y ago
  There's definitely ways, and it isn't hard, but AWS charging heavily for egress data. I've had bills with AWS that were $200 a month, where $160 of that was egress charges.
WJW 6y ago
As long as you keep paying, of course.

goatinaboat 6y ago

That's why I think as long as you have documented and defined your methods (i.e. business logic) well, and your data is portable, you shouldn't worry much about vendor lock-in in the long run. That's a huge big IF. In many if not most cases the only reliable documentation of a system is the running code itself.

Ma8ee 6y ago

In most cases, the only reliable documentation and definition is the code itself. It's is rare for most of us where it is hard to figure out how to do something. In general the only hard part is to figure out exactly what needs to be done.

sltEvas 6y ago
Actually, code isn't what does that. It's true that code is one of the things that keeps it "all". However, it's not the best place for documentation or even storage of that knowledge. Code changes. Tests are what you need to invest in. When you test all of you business use cases in an abstract (perhaps even no-code) way, you are truly independent. You can rewrite the system very quickly, if you had a test-suite that allows for quick iteration (TDD style) and does not depend on implementation details. Given just the code? Well good luck migrating to another cloud vendor. You will probably introduce one million bugs on the way.
- ironSkillet 6y ago
  What are some techniques you use to test business use cases in a code independent way?
  - loopz 6y ago
    You'll want to test against stable API/ABI, and use positive and negative testcases. The problematic parts are mocking, simulation and how tests affect the codebase.
    - redis_mlc 6y ago
      > You'll want to test against stable API/ABI Good luck with that. lol. - The only stable APIs I've seen, if an API exists, are production financial APIs, because money is involved. - DynDNS has been knows to change input and output parameter types, breaking calls - Even Twilio has changed a fundamental API path (!) in the past couple of years, breaking SMS API calls in 2019 - Facebook only supports API version N and N-1. Hope you're not on N-2 and there's a sudden version bump! (I say production APIs, since even payment gateways often have flaky dev/qa gateways that you can't reliably do automated tests against. Past companies that I worked at had to test against prod gateways with their own personal credit cards.) Otherwise, if you want an API, ensure you choose a product/partner that offers/supports one.

m463 6y ago

Taking the 10,000 foot view that "code is temporary"... I think "business logic" is indeed temporary. With very few exceptions, most code you write for someone else will not stand the test of time. In fact, most of the companies I've worked for do not exist or have greatly changed over the years. MIT/BSD software is a little better. And strangely - GPL software does stand the test of time.

wintorez 6y ago
I think my usage of the term "business logic" was a bit misleading. What I meant was more the methods and ways which we expect the data to be processed; more like requirements than anything.
nyanpasu64 6y ago
Is it because MIT/BSD software is more common in web or scripting language cultures, where code tends to be replaced faster? Or more common in newer code which most will not survive for years?
- AnthonyMouse 6y ago
  MIT/BSD licenses allow for proprietary forks. The most popular BSD-based kernel is Apple's, which isn't distributed under the BSD license. The most popular GPL kernel is Linux, which still is. So with the BSD license somebody can take your work, improve it, distribute it under a proprietary license and supplant you in the market. Compare macOS or iOS installed base to FreeBSD. But then the codebase is henceforth tied to that company. If Apple is dead in twenty years then probably nobody is still using the iOS kernel (and not because they switched back to FreeBSD), but if Google is dead in twenty years most likely Linux is still popular all over.
  - 67868018 6y ago
    MacOS/iOS is not based on a BSD kernel. https://imgpile.com/images/uL3CFP.jpg https://imgpile.com/images/uL3CFP.jpg

pachico 6y ago

Not only that. Good code should be easy to throw away without major effort.

wintorez 6y ago
For me, writing code has became like making a sandcastle. I sure put a lot of time and effort in it, but I never try to preserve it. It's pointless. What I preserve is the lessons I learned while building it, and applying them to build a better sandcastle next time.

monkeydust 6y ago

The only thing that remains from code are the real world decisons and actions that come from it

deleted 6y ago

[deleted]

drewcoo 6y ago

The article presented evidence for the primacy of humans. That things are sticky because they are built for humans. Your counterclaim to this piece is that humans aren't a thing that matters. Do you have reasons?

durandal1 6y ago

Pick "boring" and battle-tested solutions and this fades. I implemented a fairly complex kickback-tracking business system 15 years ago, due to the rest of the company being entry-level PHP devs, I implemented the whole thing in pl/pgsql. 15 years later it's still ticking as the core of the business with minor modifications. And the crazy thing is, in today's world of microservices and hyperfocus on horizontal scaling, I would still implement it in pl/pgsql, and indeed, I'd expect it to keep ticking for the next 20 years as long as the company stays in business.