4 ms·

I see the author's point, and it is valid, but I'd like to give a counter example. I was asked if I could make a program that could 'put a photo on top of anot

I see the author's point, and it is valid, but I'd like to give a counter example. I was asked if I could make a program that could 'put a photo on top of another one'-- the idea being they wanted a program where you could load a template image, maybe one that looks like a birthday card, and it would have a spot where someone's picture could be put on top of the birthday card image. Simple enough, but I decided to build a generalized templating system with a built in editor so new templates could be created. This way it could make birthday cards for one person, or make a "Good Job team!" cards for multiple people. It was completely agnostic to what kind of templates you could make with it. It supported layers, conditions, database integration. Sure enough, over the course of months, I was asked to make the program do more things than it was originally asked to do, and I was able, with few exceptions, to accommodate these requests without needing to modify the source code. Even when I did need to modify source code, it was to extend functionality, not change the basic template abstraction model. It found its way into other uses as well (digital signage, ads, etc). If I had only solved the least general problem first time, I would have been back at the drawing board rewriting most of the app every time something new was requested. Maybe this is a rare counter example, but sometimes pursuing the general solution pays off.

commandlinefan 8y ago
I actually agree with both of you, _as long as it's up to the implementer_. I see requirements specifications that deliberately try to remain vague in the hopes that the developer will produce a "general" abstraction that can be reused - and always end up shooting themselves in the foot by never saying exactly what they want done. Or the "disruptive scrappy startup founders" who want you to build "legos".
tynpeddler 8y ago
I think another way of putting the title is "Right-size your abstractions." My rule of thumb is to solve the problem at hand while accommodating (but not implementing) known tasks within the next 3-6 months. If you're not designing your abstractions to deal with changes you have very good reason to believe will be coming soon, you'll be stuck rewriting all your code over and over again. At the same time, it's very difficult to anticipate requirements more than 6 months out unless you're very experienced with the problem domain and application you're working on.
jononor 8y ago
But you did not go and try to implement PhotoShop or a node-editor graphics processing tool, which would have been even more general - and likely too far.

commandlinefan 8y ago

I actually agree with both of you, _as long as it's up to the implementer_. I see requirements specifications that deliberately try to remain vague in the hopes that the developer will produce a "general" abstraction that can be reused - and always end up shooting themselves in the foot by never saying exactly what they want done. Or the "disruptive scrappy startup founders" who want you to build "legos".

tynpeddler 8y ago

I think another way of putting the title is "Right-size your abstractions." My rule of thumb is to solve the problem at hand while accommodating (but not implementing) known tasks within the next 3-6 months. If you're not designing your abstractions to deal with changes you have very good reason to believe will be coming soon, you'll be stuck rewriting all your code over and over again. At the same time, it's very difficult to anticipate requirements more than 6 months out unless you're very experienced with the problem domain and application you're working on.

jononor 8y ago

But you did not go and try to implement PhotoShop or a node-editor graphics processing tool, which would have been even more general - and likely too far.