4 ms·
> Imagine the most annoying possible client of our microservice. Suppose they want a new field, and they insist that it be named a certain way. This shows a fu
by Etheryte 2y ago
> Imagine the most annoying possible client of our microservice. Suppose they want a new field, and they insist that it be named a certain way.
This shows a fundamental misunderstanding of what code is for, at least in a production setting. Code isn't a marble statue that's supposed to be safely guarded in a museum, it's a way to get things done. Sure, for a hobby project you can polish it and perfect it like a diamond, but for business needs, the end goal of code is to do The Thing. That annoying client is why you're getting a high salary, if they didn't have their annoying needs, you wouldn't have a job.
- doctor_eval 2y agoThere is a lot more to meeting a customer’s needs than blindly doing what they say. Sometimes, you need to write code to protect them from their own (sometimes-but-not-always rational) decisions - or to protect other customers and stakeholder from them. You also need to keep your own team nimble. I’ve seen plenty of systems that have just thrown code at the product, and they end up with SQL tables with 150 columns - most of which nobody uses, and which can’t be removed, and the customer ends up pissed off anyway because you can no longer turn their requests around quickly. A good, layered design mitigates against this and makes it possible to continue to be productive even in the face of customer demands. Externalising customisations is a huge benefit to productivity.