221–230 of 339 posts
Earlier quoted context omitted.
Better be consistently boring than ever misleading
But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.
Half the article is like, "There was a component called YamlParser, which is now a browser-based stable-diffusion renderer!"
I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will say that funny names are not actually fun.
I can only imagine working in the author's ideal company:
"Hey, does anyone know why Shmoop is down? I know I updated the BoomBoom and reconfigured Thanos, but now Klomgan is reporting a series of Lemonhead warnings. Should I talk to Meep team or the Chumbawumba admins?"
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…
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 peo…
Earlier quoted context omitted.
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 peo…
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...")
But many software projects are. not. that. That's really all I'm getting at. This web service developer bubble annoys me because they never feel any onus to introduce themselves in their blogposts and caveat their opinionated recommendations with the context they're coming from. In my world of robotics, just making a random family of services with non-descript names is a bad idea. The services in the system should have roles, and if the temptation arises to add functionality beyond that role, it probably means you need to step back and do some thinking about why that happened.
Also: I know you were just making a rhetorical point, but notice that your example is still clearly some web service that we're assumed to be running :)
I agree that bad and/or misleading names are, well, bad. However, I don't agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}.
Invest time in naming things well the first time.
Invest time in renaming things to be more accurate when it is feasible.
This is terrible advice. Cryptic names are horrible. It's a layer of cognitive overhead that no one needs. Yes if it gets so big that it's out grown it's original purpose that's a problem. But if it's really big people know what it is because it's big. If it's not that big rename it!
I disagree with that. Cryptic names can become jargon, and jargon is useful in expert teams. At my last job we had a service whose role was to convert operations from system A to system B so at first we named it systemAOperationsToSystemBOperations. The name was clear but it was a pain in the ass to talk about it. We renamed it adios as a shorter name (irks like a fake acronym of the initial name) and it became way easier to talk and reason about our system. We lose a few minutes once in a while to remind juniors what adios does but we gain an efficient name to discuss the service day to day.
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…
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 ju…
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. :(
if it's projects, ideally the long-term architecture is well enough understood to give the thing a whimsical yet meaningful name (ideally not cryptic). building a page caching service? call it gutenberg or something to start. when it inevitably grows past scope, it's ok. no one will care if gutenberg also handles analytics callbacks or whatever.
classes really shouldn't change in scope, ideally, so it's probably better to be a bit more specific to their purpose.
overall this is a good hot take, if a bit broadly put.
Earlier 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.
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 Fr…
FWIW most of our deadlines are reasonable.