5 ms·

Innovating beyond libraries and frameworks

58 points by firstSpeaker 5y ago

yobbo 5y ago
In many cases, choosing libraries and frameworks is motivated by political/symbolical reasons, and might not even expected to have any technical benefits. At one point choosing java enterprise was about signalling ambition and competence. Nowadays service architectures/cloud etc serve this role of "decorative" tech choices. These types of choices factor out responsibility (of end results) from individuals while expanding their "organizational footprints" and giving their CVs a fashion make-over. Those are the incentives. There would need to be counter-incentives.
- nilshauk 5y ago
  I think one such counter-incentive could be, "whatever tech you choose you'll have to live with the consequences by owning maintenance and future development." However, in our fast-paced industry people can switch roles and jobs so quick that they'll never have to face the consequences of their tech-choices.
  - yobbo 5y ago
    > "whatever tech you choose you'll have to live with the consequences by owning maintenance and future development." But this is not in the interest of "architects", "system owners" or "buyers". They want programmers to be replaceable, not stakeholders. To "architects", frameworks/libraries make programmers replaceable, and programmers need frameworks/libraries to be marketable.
    - nilshauk 5y ago
      Yeah that makes sense. And “nobody got fired for picking technology X from large company Y”, there’s also that type of thinking.
troelsSteegin 5y ago
The suggestion is to look at Web Components. I would think, too, to look at orchestration (composition of dataflows). As a substrate, Yahoo Pipes remains an inspiration in that way.
- nilshauk 5y ago
  Your mention of composing dataflows reminded of this project https://nodered.org/ https://nodered.org/ which I haven't tried myself but sounds a bit like what Yahoo Pipes was back in the day. I'm also curious about how simple we can make self-hosting on bare metal hardware. These days I've been looking a bit into Gnu Guix where you can define a whole server system using lisp syntax. My current explorative sideproject is to try and setup a Gitea service with Guix on a Raspberry PI.
nilshauk 5y ago
Hi everyone! The author here. Happy to discuss the thoughts expressed in the article.
mattgreenrocks 5y ago
I worry that we’ve taught tech this way to some people. Squeezed out everything cool so that we could make people that happily fill in the framework blanks, dig through stack overflow when they get stuck, and tell them that career progression consists of amassing a big list of transient technologies. They deserve better.
- nilshauk 5y ago
  Yes! It's like we've taught people to fish with the new latest in fishing equipment, but we failed to teach them some tried and true fishing principles. Haha, maybe this analogy breaks down. But yeah, I find that we focus almost too hard on keeping up with framework release notes instead of trying to see if we can distill some common patterns relevant across frameworks.
  - xnorswap 5y ago
    If we've done that it's because overnight we realised we needed 10 billion fish and only had a handful of people currently able to fish. Mass mobilisation of people able to catch fish has enabled businesses to join the digital landscape. It may be true that we've not taught people in a way that's best for their long-term prospects, but had the computer science industry taken the approach of other engineering, nursing or even accounting, with strict legislated terms and certificates, and exam boards controlling quota of people able to go into computing, then perhaps it would be an ivory tower of well built and engineered software. But it would also have risked leaving most businesses behind and things wouldn't have accelerated nearly as fast.
    - nilshauk 5y ago
      That's true we might not have been able to mobilize so much productivity so quickly for business without throwing frameworks at the problem. However, I think also a lot of effort might have been wasted by reinventing wheels and rewriting application many times over because some framework or language fell out of fashion and hiring for it became difficult.
cryptica 5y ago
> we should start to value principles over patterns, patterns over libraries, and libraries over frameworks. This is very well put. I've been thinking this way for some time. Unfortunately, too many people choose patterns over principles and frameworks over libraries. Patterns applied without principles can lead to disastrous consequences. The problem with frameworks is that there's lock-in so they're less flexible and sometimes they coerce you into making sub-optimal decisions.
JonChesterfield 5y ago
I was hoping the "beyond" would be along the lines of domain specific languages. It wasn't, and I can't follow the article's conclusion. Library vs framework vs DIY seems domain specific. If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that. Unit testing also works well as structure you plug tests into. If parts of your thing occur elsewhere but the overall structure doesn't, probably want libraries for the common parts. Equally use libraries for when the frameworks that fit don't look good enough. If you can't find an adequate library, DIY time. Write your own language seems difficult to justify economically but I really like the domain/language fit you can get out of it.
- nilshauk 5y ago
  I don't think my article shuts the door on domain specific languages even though it doesn't offer it as an answer. It could be an answer. By relying a bit less on frameworks and writing more code ourselves we have the chance to make our code fit the domain we're working with better. For now I wanted to wrestle a bit with the idea of always pulling in frameworks to do things. > If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that I agree, though that often comes with some costs and tradeoffs like I tried to outline in the article.
shadowgovt 5y ago
> Codebases that lag behind on updates can become vulnerable to security exploits This is an excellent point, but I think it's always worth considering that the tradeoff isn't between third-party security vulnerabilities and no vulnerabilities; it's between third-party security vulnerabilities and first-party security vulnerabilities. It's up to your team to decide if you have the capabilities in-house to deal with those. If not, trusting to the wisdom of crowds may often be a better solution. (At the very least, if you're rolling your own crypto solution and not publishing it, take a strong look at why you're doing that and be very sure you aren't falling victim to smartest-kids-in-the-room syndrome).
- nilshauk 5y ago
  Very much agree. Though there’s a line between implementing cryptographic algorithms yourself vs. implementing cookie based authentication. Cryptography is something I’d leave to standard libraries. However, when it comes to authentication it might not be that hard to implement some cookie or token logic as long as the actual cryptography is handled by some well tested library.
ThinkBeat 5y ago
On my friend's computer netlife throws up a WoT warning. (it is mentioned in the article as where the auhtor is CTO) >"This website has poor reputation according to Web of Trust. >www.netlife.com >Users have identified the following issues: Spam I dont think most people here take WoT warnings that seriously but it might be good for the author to be aware of it.
- nilshauk 5y ago
  Wow. Thanks for the headsup! I’ll have to look into this.

58 points by firstSpeaker 5y ago

In many cases, choosing libraries and frameworks is motivated by political/symbolical reasons, and might not even expected to have any technical benefits. At one point choosing java enterprise was about signalling ambition and competence. Nowadays service architectures/cloud etc serve this role of "decorative" tech choices. These types of choices factor out responsibility (of end results) from individuals while expanding their "organizational footprints" and giving their CVs a fashion make-over. Those are the incentives. There would need to be counter-incentives.

nilshauk 5y ago
I think one such counter-incentive could be, "whatever tech you choose you'll have to live with the consequences by owning maintenance and future development." However, in our fast-paced industry people can switch roles and jobs so quick that they'll never have to face the consequences of their tech-choices.
- yobbo 5y ago
  > "whatever tech you choose you'll have to live with the consequences by owning maintenance and future development." But this is not in the interest of "architects", "system owners" or "buyers". They want programmers to be replaceable, not stakeholders. To "architects", frameworks/libraries make programmers replaceable, and programmers need frameworks/libraries to be marketable.
  - nilshauk 5y ago
    Yeah that makes sense. And “nobody got fired for picking technology X from large company Y”, there’s also that type of thinking.

troelsSteegin 5y ago

The suggestion is to look at Web Components. I would think, too, to look at orchestration (composition of dataflows). As a substrate, Yahoo Pipes remains an inspiration in that way.

nilshauk 5y ago
Your mention of composing dataflows reminded of this project https://nodered.org/ https://nodered.org/ which I haven't tried myself but sounds a bit like what Yahoo Pipes was back in the day. I'm also curious about how simple we can make self-hosting on bare metal hardware. These days I've been looking a bit into Gnu Guix where you can define a whole server system using lisp syntax. My current explorative sideproject is to try and setup a Gitea service with Guix on a Raspberry PI.

nilshauk 5y ago

Hi everyone! The author here. Happy to discuss the thoughts expressed in the article.

mattgreenrocks 5y ago

I worry that we’ve taught tech this way to some people. Squeezed out everything cool so that we could make people that happily fill in the framework blanks, dig through stack overflow when they get stuck, and tell them that career progression consists of amassing a big list of transient technologies. They deserve better.

nilshauk 5y ago
Yes! It's like we've taught people to fish with the new latest in fishing equipment, but we failed to teach them some tried and true fishing principles. Haha, maybe this analogy breaks down. But yeah, I find that we focus almost too hard on keeping up with framework release notes instead of trying to see if we can distill some common patterns relevant across frameworks.
- xnorswap 5y ago
  If we've done that it's because overnight we realised we needed 10 billion fish and only had a handful of people currently able to fish. Mass mobilisation of people able to catch fish has enabled businesses to join the digital landscape. It may be true that we've not taught people in a way that's best for their long-term prospects, but had the computer science industry taken the approach of other engineering, nursing or even accounting, with strict legislated terms and certificates, and exam boards controlling quota of people able to go into computing, then perhaps it would be an ivory tower of well built and engineered software. But it would also have risked leaving most businesses behind and things wouldn't have accelerated nearly as fast.
  - nilshauk 5y ago
    That's true we might not have been able to mobilize so much productivity so quickly for business without throwing frameworks at the problem. However, I think also a lot of effort might have been wasted by reinventing wheels and rewriting application many times over because some framework or language fell out of fashion and hiring for it became difficult.

cryptica 5y ago

> we should start to value principles over patterns, patterns over libraries, and libraries over frameworks. This is very well put. I've been thinking this way for some time. Unfortunately, too many people choose patterns over principles and frameworks over libraries. Patterns applied without principles can lead to disastrous consequences. The problem with frameworks is that there's lock-in so they're less flexible and sometimes they coerce you into making sub-optimal decisions.

JonChesterfield 5y ago

I was hoping the "beyond" would be along the lines of domain specific languages. It wasn't, and I can't follow the article's conclusion. Library vs framework vs DIY seems domain specific. If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that. Unit testing also works well as structure you plug tests into. If parts of your thing occur elsewhere but the overall structure doesn't, probably want libraries for the common parts. Equally use libraries for when the frameworks that fit don't look good enough. If you can't find an adequate library, DIY time. Write your own language seems difficult to justify economically but I really like the domain/language fit you can get out of it.

nilshauk 5y ago
I don't think my article shuts the door on domain specific languages even though it doesn't offer it as an answer. It could be an answer. By relying a bit less on frameworks and writing more code ourselves we have the chance to make our code fit the domain we're working with better. For now I wanted to wrestle a bit with the idea of always pulling in frameworks to do things. > If your thing has been built so often already that much of the logic can be factored out into a framework, great - may as well use that I agree, though that often comes with some costs and tradeoffs like I tried to outline in the article.

shadowgovt 5y ago

> Codebases that lag behind on updates can become vulnerable to security exploits This is an excellent point, but I think it's always worth considering that the tradeoff isn't between third-party security vulnerabilities and no vulnerabilities; it's between third-party security vulnerabilities and first-party security vulnerabilities. It's up to your team to decide if you have the capabilities in-house to deal with those. If not, trusting to the wisdom of crowds may often be a better solution. (At the very least, if you're rolling your own crypto solution and not publishing it, take a strong look at why you're doing that and be very sure you aren't falling victim to smartest-kids-in-the-room syndrome).

nilshauk 5y ago
Very much agree. Though there’s a line between implementing cryptographic algorithms yourself vs. implementing cookie based authentication. Cryptography is something I’d leave to standard libraries. However, when it comes to authentication it might not be that hard to implement some cookie or token logic as long as the actual cryptography is handled by some well tested library.

ThinkBeat 5y ago

On my friend's computer netlife throws up a WoT warning. (it is mentioned in the article as where the auhtor is CTO) >"This website has poor reputation according to Web of Trust. >www.netlife.com >Users have identified the following issues: Spam I dont think most people here take WoT warnings that seriously but it might be good for the author to be aware of it.

nilshauk 5y ago
Wow. Thanks for the headsup! I’ll have to look into this.