3 ms·

I've seen the other side of the coin, where the desire to solve a concrete problem forces a solution to be unnecessarily brittle and actually harder to implemen

I've seen the other side of the coin, where the desire to solve a concrete problem forces a solution to be unnecessarily brittle and actually harder to implement than a more generic solution. I'll give an example: "we're never gonna have more than three devices, so this array should have a hardcoded size of 3." It sounds pretty extreme, but believe me, some variation of this theme comes up more often than I would like, especially from people who are not software engineers. It seems like some people think that every abstraction (and potential genericity) is expensive, so they tend to put constraints in places where none need to exist. Very soon you'd need to make a small modification to your code, or extend it slightly, and those unnecessary constraints are going to make things difficult. Personally, I'd like to approach a problem from the bottom-up. Start with solving a concrete case, and see if any patterns emerge in the process. And if they do, then I generalize those patterns. Frequent refactoring is very helpful during this process. Sure, mistakes and over-generalizations can still occur. But they are usually not very expensive if noticed quickly.

muxator 8y ago
In this specific case I would say that the abstraction rises as soon as the number of devices gets >= 2. Isn't the "0, 1, n" rule a thing?
moring 8y ago
I think this conflates requirements and implementation choices. "we're never gonna have more than three devices" is a statement about requirements, and implies the absence of a requirement to support more than 3 devices. It does not imply a requirement to fail to support more than 3 devices though, and leaves an implementation choice how many devices to support, as long as it's at least 3. On the implementation side, the "0, 1, n" rules already mentioned by muxator dictates that this specific aspect of the implementation should not treat 3 different from 5, and implement support for n devices. (By "This specific aspect" I mean that other factors will surely prevent supporting n = 1 trillion, but we don't have to care about that since it doesn't contradict the requirements).
beaconstudios 8y ago
this is why I think one-way specifications are a massive anti-pattern in the software industry. Often times the developer, who has the front-line view of the existing abstractions, could turn a 4 week project into a 1 week one just by adjusting the spec, while still solving the actual problem.

muxator 8y ago

In this specific case I would say that the abstraction rises as soon as the number of devices gets >= 2. Isn't the "0, 1, n" rule a thing?

moring 8y ago

I think this conflates requirements and implementation choices. "we're never gonna have more than three devices" is a statement about requirements, and implies the absence of a requirement to support more than 3 devices. It does not imply a requirement to fail to support more than 3 devices though, and leaves an implementation choice how many devices to support, as long as it's at least 3. On the implementation side, the "0, 1, n" rules already mentioned by muxator dictates that this specific aspect of the implementation should not treat 3 different from 5, and implement support for n devices. (By "This specific aspect" I mean that other factors will surely prevent supporting n = 1 trillion, but we don't have to care about that since it doesn't contradict the requirements).

beaconstudios 8y ago

this is why I think one-way specifications are a massive anti-pattern in the software industry. Often times the developer, who has the front-line view of the existing abstractions, could turn a 4 week project into a 1 week one just by adjusting the spec, while still solving the actual problem.