Comment by dkarl | Hacker News Reader

Comment by dkarl | Hacker News Reader

Parent Full thread

Reminds me of a conversation I had with a project manager. To match the example, I'll recast it in terms of deadlines.

Project manager: Sam is working on a deadline validator. You made a deadline validator last sprint right? Could Sam use yours?

Me: No, unfortunately not. My deadline validator enforces that deadlines are in the future and are aligned with midnight UTC, to ensure correct date calculations in the database. The deadline validator Sam is working on does not enforce those restrictions. Sam's deadline validator will be applied to user input for an entirely different field, where deadlines don't have to be at midnight and are just as often in the past as in the future. In fact, Sam's validator only checks that a deadline string has the expected format and is within twenty years of the present day. My validator operates on timestamps sent as integers from another service, not string values uploaded by users.

Project manager: So your deadline validator is not reusable at all? That's unfortunate. Is there something we could have done differently to avoid this redundant work?

> In fact, Sam's validator only checks that a deadline string has the expected format and is within twenty years of the present day.

You two have been talking about this longer than it took Sam to implement by now ;)

This is one of those things that's easier to respond to with more experience. When I was a more green developer just starting to work in a team, I'd probably have answered, "Yes, I could've tried making the code more open-ended and extensible for such a scenario."

Now, with decades of experience, I can answer, "No, because if we designed all of our code to be reusable for any potential use-case, we'd be adding in a ton of extra work that would often not pay out later. It's acceptable that if we go with a YAGNI principle that occasionally we'll have some code that seems to be duplicated work, but that's far better than constantly writing more code that we don't need as that will increase our design complexity, leading to longer development time and requiring additional testing."

Developer, next time: No, I made a real-time database constraint policy enforcement engine. Totally different thing.

This really hit close to home. Many years ago a project manager said the same thing to me. Unfortunately in that case, Sam's new deadline validator has much more simplified requirements than the developer's. The developer's deadline validator takes ten function arguments to customize its behavior in various ways. One of the arguments, a stringly typed argument allows the validator to match the fraction of the second against a string. Sam thought providing the empty string "" would ask the validator to accept all possible fractional values, but unfortunately it requires the magic string "*" to accept all possible fractional values and the empty string "" only allows zero fractional values, i.e. the deadline must be an integral number of seconds.

An outage happened because the system rejected every single deadline that's not an integral number of seconds.

Reply on news.ycombinator.com