3

I have one text box across multiple pages which is used to enter multiple customerids (as comma separated) . But in current page due to some subsequent implementation difficulties we make it as customerid so that user can enter only one customer not multiple customerids as comma separated.

But coding styles and naming of variables across all pages are same since we are assuming that multiple customerids could be entered in future.

we are having array instead of string to store customerid as given below:

customerIds.push(tbxval); 

whereas customerids array always having only one element inside that as of now in that particular page.

I guess if that future requirement not asked from product owner, this code could make some problem or at least until that requirements comes.

But I'm not sure what kind of negative or positive impact it could make.

  • 2
    there's no right answer here... it's a cost- benefit risk management thing... with what certainty do you believe the requirements will change? how much are you sure about the nature of the change? how much does it cost to prepare in advance and is it even worth it? – AK_ Apr 25 '15 at 9:42
  • see also: Dealing with bad/incomplete/unclear specifications? – gnat Apr 25 '15 at 12:13
4

If we interpret this question in its most general sense, the proposed duplicate question has perhaps the best answer you could ever get:

Too often when you try to design for the future, your predictions about future needs turn out to be wrong. It's usually better to refactor when you actually know how the needs have changed than to overdesign your system on day one. At the same time, don't shoot yourself in the foot, either. There's certainly a middle ground, and knowing where that is is more art than science.

To boil it down to one rule of thumb: less is more.

But we can expand on this a bit. There's a big difference between trying to predict the future, and actually knowing the future.

It is important for developers to be aware of the long-term vision of the product because once in a while, you really do know for sure that you will need to do X at some point in the future. For instance, I know that our application will have to support color themes someday, so I try to avoid relying on the current default color values as much as possible. But I haven't written any code to change the default colors, because we won't need it for a very long time, and I have no idea how exactly we'll want it to work. We also knew from the start that our application would need internationalization, so we (mostly) kept user-facing strings and "code-only" strings clearly separated from day one, even when we didn't have a system for translating the user-facing ones yet.

In your example, it's not clear whether dealing with an array instead of a single number would result in you writing additional code you don't need yet, or just slightly different code. It's also not clear whether you know you'll need this in the future or if you're just guessing. Only you and your product manager can answer that. If the odds are high that you will need arrays, and using arrays doesn't make the code significantly more complicated right now, then it's probably a good idea to start using arrays early.

The only time it might be worth trying to predict the future and be more generic than necessary is when you're designing an API, schema or file format that needs to be backwards compatible. For example, if you have a web service API with a method getPublicUserStats(), making it only accept a single user id instead of an array is needlessly restrictive, even if you only need one at a time right now. But you shouldn't go out of your way to optimize for requests with a thousand user ids until you actually have a performance issue.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.