naming a project != naming a variable
Software component names should be whimsical and cryptic
191–200 of 339 posts
Re: Software component names should be whimsical and cryptic
#192Earlier quoted context omitted.
Sure but what to do if all the good names for doing the thing the thing is doing are taken ?
When faced with the same problem, Elon went with X Æ A-12. Personally I prefer UUIDs for global uniqueness.
c88990d0_c47e_4d8a_aa96_680d8b58192d_Service aka OrderService
ca7f6516_337c_11ed_a261_0242ac120002_Service aka PaymentService
Re: Software component names should be whimsical and cryptic
#193Author 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…
> 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.
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.
Re: Software component names should be whimsical and cryptic
#194Radical idea: If the usage/purpose of something diverges significantly from its original name, change the name.
Re: Software component names should be whimsical and cryptic
#195I don’t understand why it’s seen as a given that component names can’t be changed. All the given examples are public project names, where there’s a point to be made. For internal components though, where are your refactoring tools?
Re: Software component names should be whimsical and cryptic
#196In our stock trading algorithm, a parent order could have multiple child orders. If the parent order quantity was amended down, it might be necessary to cancel some of the child orders. The function name for this was called getSophiesChoice()
Re: Software component names should be whimsical and cryptic
#197Author 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…
> 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.
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).
Re: Software component names should be whimsical and cryptic
#198Earlier quoted context omitted.
I abbreviated on the phone, but the respective full names are “X Enterprise Linux” and “X Web Services” which are literal description of what their thing is. “RedHat” and “Amazon” are generic, but the product names are highly specific. I mean it could’ve been “RedHat Cthulu” and “Amazon RainBox”.
I strenuously dispute that "Web Services" is "highly specific".
It is about as specific as the product.
Re: Software component names should be whimsical and cryptic
#199I work at a company where all of our services have stupid Greek code names. It adds a layer of obscurity, increases the cost of onboarding devs and context switching, etc. It's a goddamn stupid idea.
The author here is equivocating opaque code names with multi-use repos. They're saying "see!? some repos on github do things in addition to their literal name."
That has nothing to do with the fact that obscure code names are a stupid anti-pattern.
Re: Software component names should be whimsical and cryptic
#200Earlier quoted context omitted.
> 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.
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.
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.