[HN Gopher] No-Code and the IKEA Effect: Software lock-in evolve...
___________________________________________________________________
No-Code and the IKEA Effect: Software lock-in evolved to make us
never churn
Author : maguay
Score : 66 points
Date : 2020-10-31 13:57 UTC (9 hours ago)
(HTM) web link (capiche.com)
(TXT) w3m dump (capiche.com)
| qwerty456127 wrote:
| I don't use Ikea furniture because I have to assemble it. It's
| just, cheap, reasonably good, easy to find and get. The idea of
| having to buy a non-Ikea desk scares me because I have no idea
| where to buy it (I'd have to spend time googling, analyzing and
| coping with uncertainty), I believe it's going to be expensive
| (which also implies I'll spend the rest of my life worrying about
| damaging its surface) and heavy. With Ikea I just go there and
| get whatever I need (+ an awesome Swedish dinner and best coffee
| ever).
| ky3 wrote:
| > I buy Ikea furniture not because I have to assemble it. I buy
| it because it's cheap, reasonably good, easy to find and get.
|
| Ftfy
| benjaminjosephw wrote:
| > We may have complained for decades when software locked us in;
| now, we're happy to stay.
|
| Being willing to trade-off higher costs and less control in order
| to use new technology is commonplace in consumer tech. Nobody has
| ever been "happy" about this vendor lock-in, why would no-code be
| any different?
|
| The current proprietary tools are valuable but they don't allow
| users to export their creations between vendors offering the same
| functionality - that means they are more locked-in then ever.
| Users have the added emotional element of having to abandon their
| creation and accept the sunk-cost if they want to switch. I'm
| quite sure that nobody is happy about that fact.
| yowlingcat wrote:
| > I'm quite sure that nobody is happy about that fact.
|
| Indeed. I think the original post may have mistaken effect for
| cause. We can look across the course of human history at many
| cases of authority figures and those who interact with them,
| but generally, forcing any kind of lock-in has weird second
| order effects, and sometimes "the cure is worse than the
| ailment" -- so too I think it could be here.
|
| What would be needed to show this? Portability, for one. The
| open-core model exists for a reason. Software lock-in needs to
| be voluntary to be defendable. If you don't make it easy for
| your users to switch, you have no proof that they are staying
| with you because you are the best option, not just what they
| are forced to use. This can be very dangerous for an
| organization which takes its incumbence for granted, which is
| basically every large B2B sales-led SaaS org, almost by
| default.
|
| It means that when an upstart figures out how to out-execute
| you, you will have ossified into a living fossil whose organs
| they will consume from the inside out all in one go, rather
| than getting advanced notice ahead of time while you can still
| course correct. Convenience is great and all, but on a long
| enough corporate lifecycle/lifespan (and they seem to be
| getting shorter and shorter these days), un-sustainability
| eventually takes its toll.
| ozim wrote:
| https://en.wikipedia.org/wiki/Data_portability
|
| There is data portability in EU and you can get all your
| data... But it probably is useless or at least not as useful
| as in context of the SaaS you were using.
| wizzwizz4 wrote:
| There's a legal requirement for data portability. That's a
| different thing.
| wintorez wrote:
| 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.
| monkeydust wrote:
| The only thing that remains from code are the real world
| decisons and actions that come from it
| rvense wrote:
| > 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 wrote:
| 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.
| dustingetz wrote:
| Big data is permanently in AWS
| wintorez wrote:
| Asking this out of my ignorance, but there're no ways of
| exporting and extracting big data out of AWS?
| WJW wrote:
| As long as you keep paying, of course.
| goatinaboat wrote:
| _Big data is permanently in AWS_
|
| Egress costs make sure of that!
| goatinaboat wrote:
| _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.
| rufus_foreman wrote:
| 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."
| Ma8ee wrote:
| 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 wrote:
| 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 wrote:
| What are some techniques you use to test business use cases
| in a code independent way?
| m463 wrote:
| 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 wrote:
| 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.
| teddyh wrote:
| > _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 wrote:
| 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 wrote:
| 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 wrote:
| 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".
| core-questions wrote:
| > 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)
| pachico wrote:
| Not only that. Good code should be easy to throw away without
| major effort.
| wintorez wrote:
| 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.
| Edmond wrote:
| 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.
| feoren wrote:
| 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.
| wintorez wrote:
| 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 wrote:
| 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 wrote:
| 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.
| AstralStorm wrote:
| Most of the paintings get lost, even sometimes
| masterpieces.
|
| Bloodlines die out or change enough to not be
| recognizable.
| mathgeek wrote:
| > 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.
___________________________________________________________________
(page generated 2020-10-31 23:00 UTC)