|Pathologically Eclectic Rubbish Lister|
Re^4: List::MoreUtils before, after and ... between? (all that is wrong with the software industry)by tye (Sage)
|on Feb 22, 2012 at 03:11 UTC||Need Help??|
So, you reject simple now, in favour of complicated,
Nope. I rejected "somewhat simple and clever now" for "even simpler and not clever (now)" while also gaining "works correctly in an easily likely but not explicitly called-out situation" and also gaining "less likely to have to be completely rewritten when the requirements are 'refined'". It was a win-win-win. It wasn't even a trade-off.
And I don't see any "speculative requirements". I find "take rubbish away from the top and the bottom" to quite clearly indicate that "'no rubbish' means 'nothing to take away'". So I consider ikegami's interpretation of "'no delimiter' means 'nothing to leave behind'" to simply be incorrect.
Considering edge cases even when they aren't explicitly given in the one example provided is not a "problem". The idea of extending a rabid "you're not going to need it" to even include "edge cases will never happen" is not something I've seen before or ever expected to see. So thanks for that novelty.
Even if I couldn't imagine how I'd end up with "no garbage in front" or "no garbage behind", I'd still prefer a solution that doesn't throw away the non-garbage when "the impossible" happens. Not to the point of choosing a significantly more complicated solution, of course. Actually, considering some edge cases often leads me to a better abstraction which leads to simpler solutions and even more often to more cohesive and better factored solutions.
instead of just taking care of the real requirements as they exist now
Providing "requirements" is not an easy task. It my experience, it is never done perfectly. Very often, it is done quite badly. I think I dealt with incorrect requirements having been provided on 3 or 4 separate projects just today (at work).
So, no, I'm not likely to "just take care of the current requirements" and avoid contemplating that the requirements might be incorrect and/or incomplete (they almost always are; though I didn't have that problem with this simple request).
Even when I have the luxury of talking directly and in-person with the person whose need I am supposed to be addressing, getting reasonable requirements is still quite an art. I certainly don't go "Oh, and here is one example; so, no need to even speculate about requirements!".
Not that I just "make up" requirements and then run off to waste time implementing over-complicated solutions based on those unconfirmed speculations (as I covered in detail before), of course.