3 ms·

>prototyping is only as useful as it is easy to trade out for the eventual solution It is also useful if you find out from prototyping that the project is not

>prototyping is only as useful as it is easy to trade out for the eventual solution It is also useful if you find out from prototyping that the project is not viable. Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit. (Although in this particular case I think using SQLite only saves you initial configuration time.)

kbenson 14y ago
> It is also useful if you find out from prototyping that the project is not viable True. I considered this when writing the reply, but decided to not obfuscate my point. It's good that you brought it up and it got addressed though. :) > Also, in general, if you need to iterate a lot using something that iterates faster at the prototype stage would have extra benefit I'm not sure it's worth it if it's significantly different than the eventual solution will be (and you're fairly certain it won't map). That can be as simple (and horrible) as prototyping against NoSQL when you know production will be SQL (or vice-versa), or as subtle as using a feature present in one RDBMS which is buggy or non functional in a different RDBMS, which is the one that will be used in production. The longer you code using the prototyping data store, the more likely you are to inadvertently use a feature which will cause you problems later in production. Now, SQL is fairly standardized, and SQLite as a prototyping tool is unlikely to cause a problem later if the production environment is a full RDBMS, but you may end up not using a few features only available in the full RDBMS that could have lead to a cleaner and/or more performant solution.