3 ms·
the big issue here is neither DRY nor YAGNI (and they're not solutions either), but this: "Next week, your PM comes back and says..." "then your PM says..." y
by locallost 6y ago
the big issue here is neither DRY nor YAGNI (and they're not solutions either), but this:
"Next week, your PM comes back and says..."
"then your PM says..."
you cannot abstract in code somebody's opinion, at least not other people's. the number of possibilities is too high, and you have no clue what they are. this is why your carefully crafted structure will break down -- it has no basis in reality.
sidenote: if you will call yourself an engineer than you need to think on a different level than implementing somebody's whims. but of course a lot of of this type of work is fiddling with things to make somebody happy. I would think a real engineer would provide a technical solution to a non-technical person for them to fiddle with themselves.
- dsego 6y ago> this is why your carefully crafted structure will break down -- it has no basis in reality. This is spot on. And also, DRY is for concepts and abstractions, not just duplicated lines of code. Picking the wrong abstractions often has a much higher cost down the line than some duplicated code.
- mypalmike 6y ago> I would think a real engineer would provide a technical solution to a non-technical person for them to fiddle with themselves. Fiddling is one thing, and designing a system to enable fiddling is something engineers often do. But a lot of PM requests aren't even close to fiddling. If your product is a streaming video service, adding DVR capabilities is something a PM might request. No amount of non-technical fiddling will enable that functionality. But a well-designed architecture with isolated functional components will make the work of adding such a feature far less painful than a poorly designed one would.