>Cheap fast prototypes can and generally should skimp on "correct" scaling things
Prototypes don't go into production, so it is moot. No, first versions should not skimp on correctness. It saves virtually no time at all. For example, I've done absolutely nothing special to make our web apps scalable, we just use scalable tech to build it in the first place instead of garbage.
>Be serious; lives aren't generally on the line
How is that relevant?
>I completely disagree.
Maybe you should try it sometime then.
>Sounds like you need to spend some time running a business and paying for those programmers
Almost 6 years so far, how much more time do I need to spend before reality will suddenly flip on its head and doing things wrong will suddenly become awesome?
> Prototypes don't go into production, so it is moot.
Yes they do.
> No, first versions should not skimp on correctness.
Yes they should.
> It saves virtually no time at all.
It saves plenty of time.
> we just use scalable tech to build it in the first place instead of garbage.
We aren't talking about tech, but technique. There are plenty of times you can do things in a less than optimal fashion that is much quicker to code than the optimal version which isn't worth doing unless the idea gets some traction.
If it goes into production, then it is not a prototype by definition. Since you are making the claim that doing things right is so much more time and effort, could you give an example of that happening? As I've gotten more experienced over the years, and built up a greater mathematical knowledge, I've found that writing correct code has saved me time, not cost it.
> If it goes into production, then it is not a prototype by definition.
That's not what prototype means to me. A prototype is a first cut that's enough to try an idea out with real users, but is built by optimizing developer time only, not performance or scalability. If an idea is validated, you can come back and optimize things, add caches, optimize db queries to pull minimal required fields or add paging or all of the dozens of little things you can skip to save time that don't add functionality but do add scalability to either traffic or a full database. This has nothing at all to do with mathematical knowledge.
It's not about correct code vs wrong code, it's about the right code for the situation. Bad ideas don't need scalable code and scalable performant code is not as fast to write as quick and dirty code. Quick and dirty doesn't mean wrong, it means working but not optimal.
Sometimes you write these quick and dirty things to let the business guy try his idea out and if it fails, as it often does, then you've not wasted time or money making something scalable and performant that doesn't need to be.
Production code is code that has had the optimization pass after you've decided an idea is worth the effort.
Prototypes don't go into production, so it is moot. No, first versions should not skimp on correctness. It saves virtually no time at all. For example, I've done absolutely nothing special to make our web apps scalable, we just use scalable tech to build it in the first place instead of garbage.
>Be serious; lives aren't generally on the line
How is that relevant?
>I completely disagree.
Maybe you should try it sometime then.
>Sounds like you need to spend some time running a business and paying for those programmers
Almost 6 years so far, how much more time do I need to spend before reality will suddenly flip on its head and doing things wrong will suddenly become awesome?