[HN Gopher] The reusability fallacy - Part 3
___________________________________________________________________
The reusability fallacy - Part 3
Author : galaktor
Score : 60 points
Date : 2020-03-28 13:22 UTC (9 hours ago)
(HTM) web link (www.ufried.com)
(TXT) w3m dump (www.ufried.com)
| m3kw9 wrote:
| From my experience actual good reusable code are very small and
| usually relatively simple great specialized task. As the
| component get more features, and when you use it, you are in a
| trade off situation where this works, but it doesn't fully do
| exactly what the requirement needs orbit does way more than it
| needs
| discreteevent wrote:
| Szyperski also said this back in 1997. "Maximizing reuse
| minimizes use"
|
| https://books.google.ie/books?id=U896iwmtiagC&pg=PA45&lpg=PA...
| danielovichdk wrote:
| I think about reuse in a couple of different ways.
|
| I do not copy paste the same exact code multiple places. Then i
| use the same code.
|
| If the code is not exactly the same, it's not a copy, hence it's
| not up reuse.
|
| I do not generalize code before 3rd strike and refactor can be
| applied, and then I still use a lot of time thinking if it might
| a premature optimization.
|
| I write microservices the same way as i write methods. If i copy
| and paste the exact same microservice, it might be up for reuse
| (3 strikes). If it's reuse, the same specifics applies as when
| programming a method or type.
|
| I would never ever write any new code with reuse in mind. It's
| arrogant to think one can forsee the future, and that's exactly
| what writing for rejse is about. Start small, evolve.
| galaktor wrote:
| Part 1: https://www.ufried.com/blog/reusability_fallacy_1/
|
| Part 2: https://www.ufried.com/blog/reusability_fallacy_2/
|
| Part 1 was posted previously but without much discussion:
| https://news.ycombinator.com/item?id=22583605
| whack wrote:
| The "fallacy" breaks down pretty quickly when we consider its
| implications. If we were to follow the suggestions given, we
| shouldn't be using:
|
| - Email services such as SES or Sendgrid
|
| - Password auth services such as Firebase
|
| - Chat services such as Twilio
|
| You might say those are extreme examples, and that's the whole
| point. Clearly there are a ton of use-cases where it makes sense
| to build reusable services once, and using it across many
| clients. Not just for "enhancements", but as an integral part of
| your service's functionality. So how and where do we draw the
| line between reusable services and avoiding service-dependencies?
| That's the real question we should be asking, and one I don't see
| being answered in the article.
| chrismarlow9 wrote:
| This is what I was wondering. The entire concept of AWS is
| built around "re-use". Forgive me if I'm wrong but didn't Bezos
| decide to rebuild amazon because of technical debt and wanted
| to build independent "re-usable" components. The entire thing
| was modeled as though teams were really companies. Each
| "team/company" (think of RDS as a team) defined their API to
| the overall guidelines, and then other teams interacted with
| them to make use of their service. He realized the business
| case for this and AWS was born. Maybe that's just some fake
| story I read somewhere.
|
| Anyway the entire concept of B2B also challenges this. We don't
| build a new company each time we need something new. Even
| assembly language doesn't agree with this.
| meheleventyone wrote:
| I look at it like this. It's super useful to have a screwdriver
| that has an adaptor that will take many different kinds of
| bits. It would be super painful to have a really configurable
| bit that could with some work fit any screw.
|
| My exemplar is a library for doing things with grids. It
| supported any kind of 2d grid. It was an amazing piece of
| design from a conceptual standpoint. Super generic, clean and
| with some impressive demos doing very non-standard things. It
| was also much easier for me to write my own grid implementation
| for my usecase than learn how to use.
|
| Being reusable because you do something well is great. Being
| "reusable" because you can be made to do one thing out of a
| bunch once you learn how is not. From a business point of view
| it's about how valuable that flexibility is and generally I
| think if it's not part of the core business you are better
| finding an inflexible fit rather than a flexible thing you have
| to sculpt to work. Simply because the latter takes focus away
| from what you are actually trying to do.
| nikanj wrote:
| Java has the opposite problem. One of the often repeated taglines
| is "If you're unhappy with X, you can easily replace it with Y,
| Z, or Q!"
|
| I just want one well-working thing, not twenty alternatives -
| seven of which turn out to be abandoned, three incomplete, one
| only works with Java 15 beta, and two are actually forks of the
| same abandoned pre-Oracle blogpost from Sun.
| ivanbakel wrote:
| >The latest paradigm "Microservices" became popular in the mid
| 2010s.
|
| Microservices isn't for re-usability. It's main benefit is better
| encapsulation, which should let you do independent resource
| management/deployments/failures.
|
| >If we look at reusability, we notice that this is the tightest
| form of coupling possible: If the reused part is not available,
| the reusing part cannot complete its work by definition.
|
| What? This is a weird nothing-burger of a sentence. Why can't
| multiple components re-use some resource without gracefully
| handling any failures? Why does re-usability mean "cascading
| failures by design"?
|
| >An important property of reuse is that the reusing part ... does
| not work without the reused asset ... The reused functionality is
| an integral part of the solution that (re-)uses it.
|
| Oh, I see: because the author has defined it this way. Then the
| article goes on to try to argue a semantic difference between
| "usability" and "re-usability", in that usable components can be
| re-used independently, but in a way that can gracefully fail! So
| the whole thing is just begging the question.
|
| There's no argument here as to why I can't write a distributed
| component with an eye to it being re-used in the future. There is
| no criticism of re-use in distributed systems. The only criticism
| is of tight coupling, which is totally valid, and then saying
| that re-use _demands_ tight coupling, which is not substantiated.
| hinkley wrote:
| Or independent rewrites.
| jungturk wrote:
| >An important property of reuse is that the reusing part ...
| does not work without the reused asset
|
| Its also naive to expect that implementing your own local
| provider (if even an option for you) will generally improve on
| the reliability over a remote/reused provider.
| smitty1e wrote:
| > Microservices isn't for re-usability.
|
| Isn't that AWS Lamdba environment getting reused at a very high
| frequency?
|
| Maybe what we should consider is that coarse-reuseabulty--
| thinking OS and container images, cloud services--works semi-
| well, but that the more fine the grain of the re-use at the
| application level, the more TFA author's points kick in.
___________________________________________________________________
(page generated 2020-03-28 23:00 UTC)