Hacker News new | ask | show | jobs
by gknoy 1596 days ago
My guess is, it has to do with how you handle 1, 2, N. The first time we write something, we write it just for that specific case --- no point overengineering if you don't know you'll need it. (Hence the "YAGNI" advice that is common.)

Now, there are two things that code has to handle. You could put in a simple bit of special-case logic, or a case statement, and move on, OR you could instead spend time, codes, and tests making it robust to handle many different types of input, with a type-specific config system that makes it easy to add new type-specific behavior.

Our predilection on many teams is to skip the middle part, and write robust automation the first time we hit a special exception. ("This used to be about ordering burgers but now we want to also order shakes, and they don't have a cook-time.") It seems like the OP was suggesting that we do a "crappy" good-enough solution to that intermediate phase of complexity, as there's a chance you might not need more than that.

1 comments

Exactly, great explanation