8 ms·

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs as

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing a design up-front, or drawing diagrams of how your system works, then this indicates one of two things about your background. 1. You're a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features 2. You work on some fucking web service. Either way, your advice does not apply to the software engineering profession as a whole. Believe it or not, lots and lots of people write software, and not all of it is a web service or some tool / framework to help run your web service. There are many things out there are that can be envisioned, designed in detail, and implemented. And, crucially, in those cases, _it is wise to do so_. I know I'm being overly dramatic, but it consistently enrages me reading blog posts that, through ignorance or deliberate omission, speak as if the world of software is just writing web services.

hbrn 4y ago
> you are doing a bad job of producing an up-front system design Or, it could be that you're actually innovating and requirements are changing faster than you write code. A late change in requirements is a competitive advantage. There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
- sidlls 4y ago
  It’s not “innovative” to double-down on mistakes.
  - hbrn 4y ago
    Not necessarily, but could be. Have you heard of brainstorming? The worst thing you could do is to ban mistakes. Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes. Being sloppy also leads to mistakes. Presence of mistakes doesn't tell you much. But lack of them tells a lot. If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.
- marcosdumay 4y ago
  I have nothing against undescriptive product names. But if you are constantly changing the entire problem your software is intended to solve, you have a problem. And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.
  - __t__ 4y ago
    Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too. Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.
    - marcosdumay 4y ago
      > Real world problems can change very quickly and as such, software changes too. So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.) The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.
      - jstimpfle 4y ago
        You make a new one and what name will it get? :)
        marcosdumay 4y ago
        Well, as I said earlier, I don't care much about what camp you side here. The one important thing is that if you decide you must solve some completely different problem, you should do it with a completely different product. So the argument that a nondescriptive name allows you the freedom to change the product is bad. You never have the freedom to change the product.
- mindcrime 4y ago
  There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing. This strikes me as a false dichotomy. The choices aren't limited to "BDUF" OR "NDUF" (No Design Up Front). There's a continuum along which the amount of up-front design that is required can range. I prefer the term SDUF (Sufficient Design Up Front). And of course we all have to keep in mind that design and architecture aren't things that only happen "up front". Design and architecture work-streams should continue throughout the lifecycle of the project, IMO. The relative weighting of the different work-streams can vary, but the key is that it doesn't just end after the first (iteration|sprint|phase|whatever-you-call-it).
  - bcrosby95 4y ago
    SDUF and redesign as necessary is where my job mostly falls. If we're facing an unreasonable deadline, "redesign as necessary" can turn into "just hack it in" though, which is what I'm currently dealing with. FWIW most of our deadlines are reasonable.
gabereiser 4y ago
I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService, as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus. Often times when people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name. The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does. I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection. Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.
- whatshisface 4y ago
  In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")
  - gabereiser 4y ago
    If you developed your services right. You’d have a notification service that does SMS,email,smokesignals… It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator. I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.
    - deleted 4y ago
rcoveson 4y ago
I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently. The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.
- sebastos 4y ago
  It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more like an ecosystem of organisms that will grow and adapt. But in OTHER contexts, your software components might be more like organs. If the heart has also become responsible for digestion, then it indicates your system design needs to be revisited. In lots of software projects, this is not an untenable proposition, such as it presumably is in a web service company. As somebody who works in one of those other contexts, it's important to me that the web service monoculture be correctly contextualized. Otherwise you have people cargo culting it in situations where the wisdom no longer applies. That's probably why I'm being so bitter. :(
  - rcoveson 4y ago
    I'm saying it's not just webservice monoculture. It predates the web. Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.
    - 4y ago
c0mptonFP 4y ago
- kuramitropolis 4y ago
  We don't need no security. Just here to remark that I quite like the tone of GP even though I kinda fail to see the point being made. Fuck what Web services have become and fuck the people who piled all this accidental complexity on top of what was essentially a very elegant kind of software, and could've remained one
dcow 4y ago
What bothers me about this comment is that it’s a roundabout ad-hominem rebuttal to the author’s argument. Reading the essay, I have no reason to believe the author has only ever worked on web services. But I would if I was angry and trying to discredit the author. The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name. I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.
Kiro 4y ago
WalterBright 4y ago
> speak as if the world of software is just writing web services. So true. Web services are just a distraction from real software, which is writing compilers.
theknocker 4y ago
jasonshaev 4y ago
The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky. In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...
- sebastos 4y ago
  On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service. A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a compiler, or a video processing pipeline, or a word processor, or a 3D game engine. So, just saying: When bloggers consider the headline "Software component names should be whimsical", I wish they'd spend a second to ask themselves whether their advice actually applies to any of the niche domains I mentioned, or if it's just a best practice for their fellow web service developers. Presently, there's a cultural trend that you don't have to bother with that step, and you can just write as if your audience is always the other web service people in the valley. To me, that gets very grating, and that's where the snark comes from.
  - jasonshaev 4y ago
    Asking the author to provide more context on what domain(s) their blog post is meant to apply to is a reasonable critique. However, consider whether your original post made that critique clear, or if it got lost amidst the other ... stuff. The first two lines, in particular, will immediately put some readers (myself included) on the defensive. Describing somebody's work as "some web service bs" is a bad start. And if your point had nothing to do with the "hardness" of the problems, only that those particular problems are most relevant to building web services, why not just say that? Instead of the "...somebody who works on some web service bs assumes that that's as hard as the world gets," bit.
dang 4y ago
Please don't cross into personal attack. Also, please don't fulminate in HN comments. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- JimmieMcnulty 4y ago
  Isn't describing this comment as "fulmination" snarky, which is itself a violation of the guidelines? It's at least a shallow dismissal of their opinion, for sure. How can you expect people to follow these rules when you yourself don't? Looking at your history, you[0] leave[1] comments[2] like[3] this[4] (shallow dismissals at best, and snark at worse) pretty[5] consistently[6]. What gives? [0] https://news.ycombinator.com/item?id=32808611 https://news.ycombinator.com/item?id=32808611 [1] https://news.ycombinator.com/item?id=32807734 https://news.ycombinator.com/item?id=32807734 [2] https://news.ycombinator.com/item?id=32803087 https://news.ycombinator.com/item?id=32803087 [3] https://news.ycombinator.com/item?id=32799206 https://news.ycombinator.com/item?id=32799206 [4] https://news.ycombinator.com/item?id=32798437 https://news.ycombinator.com/item?id=32798437 [5] https://news.ycombinator.com/item?id=32772307 https://news.ycombinator.com/item?id=32772307 [6] https://news.ycombinator.com/item?id=32773948 https://news.ycombinator.com/item?id=32773948
  - dang 4y ago
    Interpretations inevitably differ, but I don't think those comments come close to matching your descriptions and I can't imagine that most users would either. They seem tediously neutral to me.
    - JimmieMcnulty 4y ago
      Isn’t that the problem? You see your own shallow dismissals as tediously neutral, but others as violations of the guidelines. For example, in this comment here that I’m replying to, you caveat what you say, and yet you don’t caveat any of the comments I’ve cited as ”your opinion”, despite them being the same value judgements of someone else’s writing. “Please stop <value judgement of comment>.” Is about as textbook of a “shallow dismissal” as one could get. You don’t apply the same rules to yourself, so there’s zero reason or incentive to follow those rules for the rest of us. Edit: Hey, within an hour of writing this comment, I'm now slowbanned (a thing you at one point claimed was removed from HN). So I guess you don't like dissent either, dang? Edit2: Since I can't respond (you muted me), the community doesn't evaluate your activity objectively; you're worshipped, and aren't give feedback that represents a reflection of your actual behavior, so an appeal to the masses here isn't an effective argument. The community may disagree with you, but it's actively detrimental to say so, and will apparently create negative repercussions for the folks who do speak out, creating a "chilling effect", preventing you from getting the "bloodbath" you apparently think would be necessary for you to change your behavior. Additionally, the fact that you've made it harder for me to interact on HN as a result of this conversation is an indication that everything I'm suggesting here is even more true than I initially thought.

hbrn 4y ago

> you are doing a bad job of producing an up-front system design Or, it could be that you're actually innovating and requirements are changing faster than you write code. A late change in requirements is a competitive advantage. There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.

sidlls 4y ago
It’s not “innovative” to double-down on mistakes.
- hbrn 4y ago
  Not necessarily, but could be. Have you heard of brainstorming? The worst thing you could do is to ban mistakes. Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes. Being sloppy also leads to mistakes. Presence of mistakes doesn't tell you much. But lack of them tells a lot. If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.
marcosdumay 4y ago
I have nothing against undescriptive product names. But if you are constantly changing the entire problem your software is intended to solve, you have a problem. And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.
- __t__ 4y ago
  Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too. Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.
  - marcosdumay 4y ago
    > Real world problems can change very quickly and as such, software changes too. So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.) The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.
    - jstimpfle 4y ago
      You make a new one and what name will it get? :)
      - marcosdumay 4y ago
        Well, as I said earlier, I don't care much about what camp you side here. The one important thing is that if you decide you must solve some completely different problem, you should do it with a completely different product. So the argument that a nondescriptive name allows you the freedom to change the product is bad. You never have the freedom to change the product.
mindcrime 4y ago
There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing. This strikes me as a false dichotomy. The choices aren't limited to "BDUF" OR "NDUF" (No Design Up Front). There's a continuum along which the amount of up-front design that is required can range. I prefer the term SDUF (Sufficient Design Up Front). And of course we all have to keep in mind that design and architecture aren't things that only happen "up front". Design and architecture work-streams should continue throughout the lifecycle of the project, IMO. The relative weighting of the different work-streams can vary, but the key is that it doesn't just end after the first (iteration|sprint|phase|whatever-you-call-it).
- bcrosby95 4y ago
  SDUF and redesign as necessary is where my job mostly falls. If we're facing an unreasonable deadline, "redesign as necessary" can turn into "just hack it in" though, which is what I'm currently dealing with. FWIW most of our deadlines are reasonable.

gabereiser 4y ago

I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService, as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus. Often times when people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name. The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does. I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection. Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.

whatshisface 4y ago
In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")
- gabereiser 4y ago
  If you developed your services right. You’d have a notification service that does SMS,email,smokesignals… It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator. I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.
  - deleted 4y ago

rcoveson 4y ago

I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently. The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.

sebastos 4y ago
It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more like an ecosystem of organisms that will grow and adapt. But in OTHER contexts, your software components might be more like organs. If the heart has also become responsible for digestion, then it indicates your system design needs to be revisited. In lots of software projects, this is not an untenable proposition, such as it presumably is in a web service company. As somebody who works in one of those other contexts, it's important to me that the web service monoculture be correctly contextualized. Otherwise you have people cargo culting it in situations where the wisdom no longer applies. That's probably why I'm being so bitter. :(
- rcoveson 4y ago
  I'm saying it's not just webservice monoculture. It predates the web. Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.
  - 4y ago

c0mptonFP 4y ago

kuramitropolis 4y ago
We don't need no security. Just here to remark that I quite like the tone of GP even though I kinda fail to see the point being made. Fuck what Web services have become and fuck the people who piled all this accidental complexity on top of what was essentially a very elegant kind of software, and could've remained one

dcow 4y ago

What bothers me about this comment is that it’s a roundabout ad-hominem rebuttal to the author’s argument. Reading the essay, I have no reason to believe the author has only ever worked on web services. But I would if I was angry and trying to discredit the author. The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name. I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.

Kiro 4y ago

WalterBright 4y ago

> speak as if the world of software is just writing web services. So true. Web services are just a distraction from real software, which is writing compilers.

theknocker 4y ago

jasonshaev 4y ago

The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky. In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...

sebastos 4y ago
On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service. A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a compiler, or a video processing pipeline, or a word processor, or a 3D game engine. So, just saying: When bloggers consider the headline "Software component names should be whimsical", I wish they'd spend a second to ask themselves whether their advice actually applies to any of the niche domains I mentioned, or if it's just a best practice for their fellow web service developers. Presently, there's a cultural trend that you don't have to bother with that step, and you can just write as if your audience is always the other web service people in the valley. To me, that gets very grating, and that's where the snark comes from.
- jasonshaev 4y ago
  Asking the author to provide more context on what domain(s) their blog post is meant to apply to is a reasonable critique. However, consider whether your original post made that critique clear, or if it got lost amidst the other ... stuff. The first two lines, in particular, will immediately put some readers (myself included) on the defensive. Describing somebody's work as "some web service bs" is a bad start. And if your point had nothing to do with the "hardness" of the problems, only that those particular problems are most relevant to building web services, why not just say that? Instead of the "...somebody who works on some web service bs assumes that that's as hard as the world gets," bit.

dang 4y ago

Please don't cross into personal attack. Also, please don't fulminate in HN comments. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

JimmieMcnulty 4y ago
Isn't describing this comment as "fulmination" snarky, which is itself a violation of the guidelines? It's at least a shallow dismissal of their opinion, for sure. How can you expect people to follow these rules when you yourself don't? Looking at your history, you[0] leave[1] comments[2] like[3] this[4] (shallow dismissals at best, and snark at worse) pretty[5] consistently[6]. What gives? [0] https://news.ycombinator.com/item?id=32808611 https://news.ycombinator.com/item?id=32808611 [1] https://news.ycombinator.com/item?id=32807734 https://news.ycombinator.com/item?id=32807734 [2] https://news.ycombinator.com/item?id=32803087 https://news.ycombinator.com/item?id=32803087 [3] https://news.ycombinator.com/item?id=32799206 https://news.ycombinator.com/item?id=32799206 [4] https://news.ycombinator.com/item?id=32798437 https://news.ycombinator.com/item?id=32798437 [5] https://news.ycombinator.com/item?id=32772307 https://news.ycombinator.com/item?id=32772307 [6] https://news.ycombinator.com/item?id=32773948 https://news.ycombinator.com/item?id=32773948
- dang 4y ago
  Interpretations inevitably differ, but I don't think those comments come close to matching your descriptions and I can't imagine that most users would either. They seem tediously neutral to me.
  - JimmieMcnulty 4y ago
    Isn’t that the problem? You see your own shallow dismissals as tediously neutral, but others as violations of the guidelines. For example, in this comment here that I’m replying to, you caveat what you say, and yet you don’t caveat any of the comments I’ve cited as ”your opinion”, despite them being the same value judgements of someone else’s writing. “Please stop <value judgement of comment>.” Is about as textbook of a “shallow dismissal” as one could get. You don’t apply the same rules to yourself, so there’s zero reason or incentive to follow those rules for the rest of us. Edit: Hey, within an hour of writing this comment, I'm now slowbanned (a thing you at one point claimed was removed from HN). So I guess you don't like dissent either, dang? Edit2: Since I can't respond (you muted me), the community doesn't evaluate your activity objectively; you're worshipped, and aren't give feedback that represents a reflection of your actual behavior, so an appeal to the masses here isn't an effective argument. The community may disagree with you, but it's actively detrimental to say so, and will apparently create negative repercussions for the folks who do speak out, creating a "chilling effect", preventing you from getting the "bloodbath" you apparently think would be necessary for you to change your behavior. Additionally, the fact that you've made it harder for me to interact on HN as a result of this conversation is an indication that everything I'm suggesting here is even more true than I initially thought.