6 ms·

One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-qual

by boris 6y ago

One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.

lisper 6y ago
I dunno, there's a lot of really high quality stable software out there. It's not all crap. But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something for the ages only to discover that I had made a bad assumption, or technology changed, or the market changed, or my own desires changed. The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target.
- _ph_ 6y ago
  You are right, not all is crap. But too many people are not aware how much is crap and are pretty naive about using libraries. I don't think it is an accident, that e.g. the Java universe has uncountable numbers of libraries and Java projects have unbelievable many dependencies and e.g. Lisp has a percived lack of libraries. There are many reasons for that, but also, that Lisp programmers tend to rely on libraries less.
  - lisper 6y ago
    > Lisp has a percived [sic] lack of libraries Lisp is also widely perceived as an interpreted language. Willful ignorance does not make reality even if it is widespread.
- xupybd 6y ago
  Wow, after your comment about having the luxury of taking time I wanted to find out how. I found your website in your bio. Very impressive and very cool to see even huge successes find the time to comment on HN.
  - lisper 6y ago
    Thanks for the kind words. HN is one of the few remaining bastions of sanity in today's on-line world, so yeah, I make time for it.
- dgb23 6y ago
  > The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target. Software development is inherently explorative. Finding the right solutions is exactly that: finding, discovery, learning and play. IMO This is best enabled by fast feedback loops and highly dynamic, interactive systems and visualization. Sometimes it is possible/feasible to parametrize a tool beyond what it is supposed to be doing to enable this kind of play and discovery, but also to make the process of building data, plumbing and so on just a bit more efficient and fun. Game programmers get that: At some point while developing a game, they create the tools that produce the data, or the parameters, typically controlled with a visual interface, a configuration language or a scripting language. Level editors, state machines, behavior trees, story boards, flow scripting etc. Another field that does this well is scientific computing, they use Jupiter Notebooks etc. with integrated REPLs and graph visualization. The whole "no-code" and "low-code" trend[0] also shows that people are willing to program with constrained, visual languages. It empowers them and connects their mental model more directly to a product (instead of having to go all the way through a team of implementers for every change that could be exposed as data). [0] I personnally don't like the terms "no-code" and "low-code" at all, because they describe what it is not, instead of what it is: visual programming. It's like "no-sql": Could be anything from a configuration file, to a document db, to a key-value store or a ACID graph db.
dxdm 6y ago
This has not been my experience in backend development (and some dabbling in building small React frontends). Our building blocks are FOSS components who are quite robust and widely tested, and the bugs, mistakes and shortcuts we have to deal with are almost exclusively of our own making.
- ashkankiani 6y ago
  "There are popular bad libraries out there that people base their software on." "I use good libraries" Not really relevant.
fxtentacle 6y ago
Fully agree. At first I was inclined to comment "it doesn't" because I can easily build small but useful tools in a matter of days. But your comment made me realize that maybe the reason is just that I keep using the same old C++ libraries to avoid surprises. In my last Ruby project, critical APIs changed multiple times during development. But Boost / openssl / curl / TBB / MKL are surprisingly API stable, given how much is changed under the hood. Maybe conservative languages attract conservative programmers who conserve time by conserving APIs.
- forgotmypw17 6y ago
  I'm a high-level guy, and I avoid using anything under 20 years in existence. All the easy problems are already solved and well-documented, and less likely to break my code with a new release. I then try to write code in such a way that it would have worked 15 years ago and today both, working around platform changes. My current stack is Perl, HTML, CSS, SSI, PHP, SQLite, PGP, txt, and JavaScript. And yes, my sites do work in Netscape 2.0+, IE 3.0+, Lynx, Links, w3m, and with a few settings tweaks, also Mosaic.
  - giantDinosaur 6y ago
    I refuse to write anything that supports any IE version < 11 on principle. And I will relish the day I can kill support for IE11, which is hopefully rapidly approaching. I admit I do enjoy a stack which includes text files, though.
    - forgotmypw17 6y ago
      It seems to me like that stance does nothing helpful, only lets the developer off the hook of attempting something difficult and annoying. At the same time, it leaves human users who can't change their browser high and dry.
      - giantDinosaur 6y ago
        Worry not, in IE terms, 'rapidly' means 'within this decade', so I will unfortunately be supporting the last, not really venerable, version of it for a while. But even just messing around with CSS in old versions is painful: it's not just 'stack of 15 years ago' if you support IE6, it's also leaving out pretty much everything except the basics of text content, lest you spend really horrible amounts of time getting something to work.
systemvoltage 6y ago
Totally agree. Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again. When teaching goes to shit, you’re breeding and propagating, institutionalizing horrible ways to do something - amplified 100x because YouTubers are chasing viewership. That code camp 8 hour course is better replaced by reading good books and docs. Actually build something by thoroughly reading the docs. Now you got 100x more developers building foundational blocks that other developers blindly build atop. Study what Unix did when they were building small composable highly quality building blocks. Still used today after 45 years!
- BlargMcLarg 6y ago
  Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner. People should be moving fast so they don't end up in endless discussions regarding or spend too much time on creating a foundation for a solution that doesn't work, and to inhibit perfectionism. People should also be transitioning from "make it work" to "make it good" once it works, prior to delivering or finalizing it. This is largely a problem with people unable to shift practice according to the context, lazy developers and managers thinking "it works" means "ship it and never look back". Unfortunately, there is no cure perfect cure for lack of foresight and willingness to listen to the guy saying PoC code will cause problems at some point down the line.
  - systemvoltage 6y ago
    > Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner Lol :-D. You haven’t worked in a shop, have you?
  - giantDinosaur 6y ago
    Of course people should 'move fast', unless of course they should actually move slowly, or move glacially, or move moderately quickly, or with utmost urgency... the trick is knowing what's actually right, isn't it? That's where the metaphor breaks: this isn't like driving a car where the right speed is obvious.
joekrill 6y ago
It's not mentioned specifically, but I think this very much falls into the "Accidental complexity" bucket. In the same way he describes someone choosing to use Mathematica for solving a problem - a developer choosing an obscure technology or writing poor code is just more accidental complexity.
peterohler 6y ago
I think you are using the wrong building blocks. Build your own blocks or use ones that are solid with good test coverage and many of those issues go away.

by boris 6y ago

lisper 6y ago

I dunno, there's a lot of really high quality stable software out there. It's not all crap. But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something for the ages only to discover that I had made a bad assumption, or technology changed, or the market changed, or my own desires changed. The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target.

_ph_ 6y ago
You are right, not all is crap. But too many people are not aware how much is crap and are pretty naive about using libraries. I don't think it is an accident, that e.g. the Java universe has uncountable numbers of libraries and Java projects have unbelievable many dependencies and e.g. Lisp has a percived lack of libraries. There are many reasons for that, but also, that Lisp programmers tend to rely on libraries less.
- lisper 6y ago
  > Lisp has a percived [sic] lack of libraries Lisp is also widely perceived as an interpreted language. Willful ignorance does not make reality even if it is widespread.
xupybd 6y ago
Wow, after your comment about having the luxury of taking time I wanted to find out how. I found your website in your bio. Very impressive and very cool to see even huge successes find the time to comment on HN.
- lisper 6y ago
  Thanks for the kind words. HN is one of the few remaining bastions of sanity in today's on-line world, so yeah, I make time for it.
dgb23 6y ago
> The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target. Software development is inherently explorative. Finding the right solutions is exactly that: finding, discovery, learning and play. IMO This is best enabled by fast feedback loops and highly dynamic, interactive systems and visualization. Sometimes it is possible/feasible to parametrize a tool beyond what it is supposed to be doing to enable this kind of play and discovery, but also to make the process of building data, plumbing and so on just a bit more efficient and fun. Game programmers get that: At some point while developing a game, they create the tools that produce the data, or the parameters, typically controlled with a visual interface, a configuration language or a scripting language. Level editors, state machines, behavior trees, story boards, flow scripting etc. Another field that does this well is scientific computing, they use Jupiter Notebooks etc. with integrated REPLs and graph visualization. The whole "no-code" and "low-code" trend[0] also shows that people are willing to program with constrained, visual languages. It empowers them and connects their mental model more directly to a product (instead of having to go all the way through a team of implementers for every change that could be exposed as data). [0] I personnally don't like the terms "no-code" and "low-code" at all, because they describe what it is not, instead of what it is: visual programming. It's like "no-sql": Could be anything from a configuration file, to a document db, to a key-value store or a ACID graph db.

dxdm 6y ago

This has not been my experience in backend development (and some dabbling in building small React frontends). Our building blocks are FOSS components who are quite robust and widely tested, and the bugs, mistakes and shortcuts we have to deal with are almost exclusively of our own making.

ashkankiani 6y ago
"There are popular bad libraries out there that people base their software on." "I use good libraries" Not really relevant.

fxtentacle 6y ago

Fully agree. At first I was inclined to comment "it doesn't" because I can easily build small but useful tools in a matter of days. But your comment made me realize that maybe the reason is just that I keep using the same old C++ libraries to avoid surprises. In my last Ruby project, critical APIs changed multiple times during development. But Boost / openssl / curl / TBB / MKL are surprisingly API stable, given how much is changed under the hood. Maybe conservative languages attract conservative programmers who conserve time by conserving APIs.

forgotmypw17 6y ago
I'm a high-level guy, and I avoid using anything under 20 years in existence. All the easy problems are already solved and well-documented, and less likely to break my code with a new release. I then try to write code in such a way that it would have worked 15 years ago and today both, working around platform changes. My current stack is Perl, HTML, CSS, SSI, PHP, SQLite, PGP, txt, and JavaScript. And yes, my sites do work in Netscape 2.0+, IE 3.0+, Lynx, Links, w3m, and with a few settings tweaks, also Mosaic.
- giantDinosaur 6y ago
  I refuse to write anything that supports any IE version < 11 on principle. And I will relish the day I can kill support for IE11, which is hopefully rapidly approaching. I admit I do enjoy a stack which includes text files, though.
  - forgotmypw17 6y ago
    It seems to me like that stance does nothing helpful, only lets the developer off the hook of attempting something difficult and annoying. At the same time, it leaves human users who can't change their browser high and dry.
    - giantDinosaur 6y ago
      Worry not, in IE terms, 'rapidly' means 'within this decade', so I will unfortunately be supporting the last, not really venerable, version of it for a while. But even just messing around with CSS in old versions is painful: it's not just 'stack of 15 years ago' if you support IE6, it's also leaving out pretty much everything except the basics of text content, lest you spend really horrible amounts of time getting something to work.

systemvoltage 6y ago

Totally agree. Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again. When teaching goes to shit, you’re breeding and propagating, institutionalizing horrible ways to do something - amplified 100x because YouTubers are chasing viewership. That code camp 8 hour course is better replaced by reading good books and docs. Actually build something by thoroughly reading the docs. Now you got 100x more developers building foundational blocks that other developers blindly build atop. Study what Unix did when they were building small composable highly quality building blocks. Still used today after 45 years!

BlargMcLarg 6y ago
Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner. People should be moving fast so they don't end up in endless discussions regarding or spend too much time on creating a foundation for a solution that doesn't work, and to inhibit perfectionism. People should also be transitioning from "make it work" to "make it good" once it works, prior to delivering or finalizing it. This is largely a problem with people unable to shift practice according to the context, lazy developers and managers thinking "it works" means "ship it and never look back". Unfortunately, there is no cure perfect cure for lack of foresight and willingness to listen to the guy saying PoC code will cause problems at some point down the line.
- systemvoltage 6y ago
  > Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner Lol :-D. You haven’t worked in a shop, have you?
- giantDinosaur 6y ago
  Of course people should 'move fast', unless of course they should actually move slowly, or move glacially, or move moderately quickly, or with utmost urgency... the trick is knowing what's actually right, isn't it? That's where the metaphor breaks: this isn't like driving a car where the right speed is obvious.

joekrill 6y ago

It's not mentioned specifically, but I think this very much falls into the "Accidental complexity" bucket. In the same way he describes someone choosing to use Mathematica for solving a problem - a developer choosing an obscure technology or writing poor code is just more accidental complexity.

peterohler 6y ago

I think you are using the wrong building blocks. Build your own blocks or use ones that are solid with good test coverage and many of those issues go away.