4 ms·
Actually, under engineering is a common thing as well. It leads to systems that once they are implemented are hard to modify. Typical symptoms are people trying
by jillesvangurp 2y ago
Actually, under engineering is a common thing as well. It leads to systems that once they are implemented are hard to modify. Typical symptoms are people trying to hack around that. Or designers sacrificing necessary complexity in favor of an elegant look.
If you've ever had the discussion whether the name field is 1 text field or 2 text fields, that's what's going on. "I don't care about first name last name, we just need a single name field, much more elegant". Fast forward a few months ... "hey can you auto-magically split that name field in first name, last name".
No kidding, I've had to sit a PM down on at least two projects where that happened and explain to them why that was a silly idea. In case you are wondering, there's a good reason why most apps and sites use two fields: splitting automatically reliably is not possible and as soon as you want to address somebody by their first (or last) name in e.g. an email, invoice, etc. you need both fields. Another classic mistake here is that the first name and last name are two words. They can be multiple words. Both. And two fields is actually not enough for some names if you really want to cover everything. There's also salutations, titles, middle name, maiden name, etc. It's a mess. But you can usually get away with using just first & last name. Just one example.
It's the famous Einstein paraphrasing of making things as simple as you can; but not simpler.
The issue with over engineering is engineers getting carried away with edge cases that in practice aren't relevant. Like trying to build a super scalable web platform for a thing that has maybe a handful of active users. Optimizing a thing that only takes a millisecond in a request that takes half a second. Nice but your problem was somewhere in the 499 other milliseconds. Obsessing over the one in ten thousand users that might want feature x used in some weird way, etc.
- xnorswap 2y agoYou've correctly identified a problem, but you've come to the wrong conclusion. If you ask someone their name, a single field copes with a range of different name shapes. If you want to address them in an email with "just first name", what you're really asking for is a preferred name to be greeted by, and that should be an entirely different single field. By splitting or having "firstname/lastname" fields you're making the classic mistake about names. Ask in the sign-up or user preferences their preferred way to be greeted in an email. If the user wants their marking emails to start "Dear shithead" then free them up to do that. You could try splitting the "full name" field to pre-fill a suggested name by which to be greeted.
- Maxion 2y agoI can throw one more curveball here that currently isn't really solved anywhere. Nameless people. This situation arises when you know you want to travel after giving birth, and you want to book the tickets in advanced to take advantage of lower prices. Most airlines won't let you book a ticket without a name, nor do they let you edit names. The situation is also relevant in hospitals where babies are born, in Finland they literally put girl <surname> / boy <surname> into the system as the first / lastname. It's quite funny that a place literally designed to handle new humans, does not have a way to handle that.
- silvestrov 2y agoFalsehoods Programmers Believe About Names https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
- jillesvangurp 2y agoJust going with the principle of the least amount of surprise here. This is simply what the vast majority of websites do because it's good enough. It doesn't offend any one too much. I'm well aware of the full range of complexity offered in e.g. the vcard standard. But dumping that on the user might not work out the way you want either. There are also some cultural differences of course with E.g. Asian people using their family name first instead of last. But going with the number of fields: 1 is probably under-engineering it, 2 is probably enough, 3 would be a stretch. 4 or more is probably over engineering the problem (unless you specifically have a requirement for this).
- m000 2y ago> The issue with over engineering is engineers getting carried away with edge cases that in practice aren't relevant. My decider question on whether something is really needed: "Am I willing to write a test case for this?" This typically helps strip down functionality to the essentials, and may even prompt some minor API redesigns.