Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malleable Software

mdubakov.me

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Malleable Software

#71

Post by glitchc »

osigurdson wrote: post #68
jaimebuelta wrote: post #29

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…

I think the article presents a bit of an odd premise - I can make a mini app in ChatGPT today so by 2035 I can create an entire suite of software needed for a given business. What is the requisite change between what I can do now and in 2035? Presumably it is AGI. OK, so we are in a digital super intelligence world in 2035. The HR department can now just have a conversation with a chatbot and create software to make…

It doesn't need to be AGI to build complex software. A human software developer can build a complex software system and perform other complex tasks with the same body (play an instrument, fly an aircraft, etc.). Doing all of that with the same resources is what AGI is needed for. Just software, well I'm sure an LLM can eventually become an expert just like it learnt how to play Go.

Re: Malleable Software

#72

Post by tikhonj »

jaimebuelta wrote: post #29

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…

The best software around is Emacs. Does that count as "opinionated" in your view?

In some ways it is—Emacs does a lot of things its own way, completely unbothered by mainstream conventions—but, at the same time, it's also totally malleable in the sense of this article. What makes Emacs great is a consistent and coherent conceptual foundation coupled with remarkably flexible code, letting you adjust Emacs to your needs rather than adjusting your needs to Emacs.

Or maybe the best software around is situated software. Software that's built by and for a specific set of people in a specific social context. Situated software is qualitatively different from product software, and it works so well because, again, it gives its users real agency and control. Instead of trying to create software that knows better than its users, we can create software that supports its users in whatever ways works for me. The result is still opinionated, but it's opinionated in a categorically different way from what you're describing.

So perhaps the best mainstream software is Excel.

And, while I don't think they're there now, it seems like LLMs are likely to be the foundation for the next Excel.

Re: Malleable Software

#73

Post by 827a »

I disagree with a lot of the assertions the article makes.

IME: LLMs don't "thrive" in messy open-ended spaces. They handle spaces like that better than traditional code, and traditional code handles structured spaces a lot better, but LLMs still do perform better in structured spaces than unstructured ones. Giving them lists of tools, schemas for data, consistent examples, etc always produces better results than not doing this.

The correlate thesis you have to make is: Do humans work better in unstructured spaces. This can be true for highly creative and individual work, but generally (and especially in the enterprise SaaS world) the opposite is true. The Structure is how you keep the users of the product aligned on one pattern of usage. E.g. giving people the ability to just create whatever ticket fields they want in Linear ends up being useless because you'll end up with 10 fields that do similar things; the friction structure introduces is necessary because while it can cost a few seconds up-front as users learn how things are done, it saves time down the line as your organizational tools (filtering, dashboards, reports, etc) are aligned on the structure.

Its also 100% the case that oftentimes companies buy SaaS tools not to solve their problems, but to help them better structure the problems they have so they're even solvable at all. Think about Sentry: The end-goal of Sentry is to solve issues in web applications, for sure. But that's not why people buy it. I could do that without Sentry; but Sentry adds structure to the errors, it adds deterministic workflows to the errors, and it provides excellent SDKs to report them. Sentry's value isn't actually in the end-goal; its value is in the structure it adds every step before the end-goal. Accelerating the inputs by adding formality to them ends up accelerating the end-goal.

Re: Malleable Software

#74

Post by osigurdson »

glitchc wrote: post #71
osigurdson wrote: post #68

Earlier quoted context omitted.

I think the article presents a bit of an odd premise - I can make a mini app in ChatGPT today so by 2035 I can create an entire suite of software needed for a given business. What is the requisite change between what I can do now and in 2035? Presumably it is AGI. OK, so we are in a digital super intelligence world in 2035. The HR department can now just have a conversation with a chatbot and create software to make…

It doesn't need to be AGI to build complex software. A human software developer can build a complex software system and perform other complex tasks with the same body (play an instrument, fly an aircraft, etc.). Doing all of that with the same resources is what AGI is needed for. Just software, well I'm sure an LLM can eventually become an expert just like it learnt how to play Go.

AGI usually means "equivalent to human" while digital super intelligence generally means "smarter than all humans put together". In any case I agree that once we reach "equivalent to human" naturally it can do anything we do. That should be enough to end office jobs imo.

Re: Malleable Software

#75

Post by lioeters »

cyco130 wrote: post #10

For six years I worked in a SaaS startup that built an applicant tracking system (a tool to manage recruitment efforts in big/mid-sized companies) tailored for the local market of the country we lived in. My experience tells me that our main value was in forcing them to rethink their recruitment processes, not adapting to their existing ones that were usually all over the place. As much as I want to believe the oppos…

> good tools often force you to adopt better practices

Just wanted to highlight this excellent statement. It's like having a strict type system that enforces certain rules are always met. It provides consistency and predictability.

> rethink their recruitment processes

This context is relevant to the kind of software system that was needed. To improve their processes, it was necessary to impose an explicit top-down order to the existing mess.

Malleable software, on the other hand, feels more suited for personal computing, greenfield projects, or small teams with members working independently as well as collaboratively. Particularly in the early stages of product R&D, strict rules can be a source of friction in the creative process.

Strict better practices and well-designed tools are discovered and developed through open and flexible explorations, as a kind of distillation of knowledge and experience.

Re: Malleable Software

#76

Post by skydhash »

tikhonj wrote: post #72
jaimebuelta wrote: post #29

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…

The best software around is Emacs. Does that count as "opinionated" in your view? In some ways it is—Emacs does a lot of things its own way, completely unbothered by mainstream conventions—but, at the same time, it's also totally malleable in the sense of this article. What makes Emacs great is a consistent and coherent conceptual foundation coupled with remarkably flexible code, letting you adjust Emacs to your need…

You can either go with simple primitives and a way to combine them (emacs, excel, unix) or simple program that just works (notepad, sumatra,…). Anything else is going to be restrictive in one way or another.

Re: Malleable Software

#77

Post by ozim »

osigurdson wrote: post #68
jaimebuelta wrote: post #29

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…

I think the article presents a bit of an odd premise - I can make a mini app in ChatGPT today so by 2035 I can create an entire suite of software needed for a given business. What is the requisite change between what I can do now and in 2035? Presumably it is AGI. OK, so we are in a digital super intelligence world in 2035. The HR department can now just have a conversation with a chatbot and create software to make…

Odd premise is that AGI will have infinite bandwidth to deal with petty stuff like taking over menial stuff of HR departments.

Current AI barely keeps up with generating funny images people ask from it :)

Re: Malleable Software

#78

Post by BinaryIgor »

ethbr1 wrote: post #49
jaimebuelta wrote: post #29

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…

> The best software around is the one that's opinionated. This. And it isn't going to change. The post avoids trying to answer "Why are opinionated tools popular and effective?" The answer is that a standardized process that they encourage is often more efficient than whatever bullshit {random company} came up with in-house. Malleable software needs to produce two equivalently good outcomes to beat opinionated: 1. Im…

100%; customization maintenance burden is underrated - it simply costs a lot of time and energy to customize things; often there are better uses of this time, especially in the business context

Re: Malleable Software

#80

Post by ch4s3 »

RUnconcerned wrote: post #67
ch4s3 wrote: post #64

Earlier quoted context omitted.

Highly customizable configuration causes all kinds of problems in healthcare, and EHR customizations have actually killed people.

In my first job I had to work with healthcare software and it horrified me. There is a standard for interop, HL7, but every system implements HL7 in its own special way so there are "integration engines" to massage the data so that they all conform to the same standard. It's a gigantic grift.

The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you had a few Health Information Exchanges at state levels so there was usually a local standard if there was an HIE. HL7 FHIR is much more standardized now.

I wouldn't call any of it a grift. It's just old tech built for a fragmented archipelago of systems that didn't communicate. Also you can write a pretty good HL7v2 parser in an afternoon, I've written maybe 5 of them.

Post reply on HN