> Once you develop the ability to iterate your way to greatness, or at least to have a fighting chance of doing so, you're much more willing to crank out dodgy Version 1.0s and see what you (and your allies) can turn them into.
Yeah...but the other side of that depends on what the definition of “dodgy” is.
For example, say we have a server-based app. If the DB schema is badly-designed (usually overcomplicated), then we are truly pooched, as we’ll start to figure that out after we have a few thousand users.
If the DB design is OK, even if it is primitive and simple, then we can have naive, problematic code, yet plenty of room to grow.
I’ve learned to design for the unknown. It’s really paid off, for me, but YMMV.
If course everything is tradeoffs. Thinking in a binary known/unknown is not helpful. I prefer probabilities wherever possible.
Choosing your bias depends on your field. In a safety critical field, you rather want to be safe than sorry. In web development, move fast and break things. This isn't hard though. You usually know which side you prefer when in doubt.
Yeah...but the other side of that depends on what the definition of “dodgy” is.
For example, say we have a server-based app. If the DB schema is badly-designed (usually overcomplicated), then we are truly pooched, as we’ll start to figure that out after we have a few thousand users.
If the DB design is OK, even if it is primitive and simple, then we can have naive, problematic code, yet plenty of room to grow.
I’ve learned to design for the unknown. It’s really paid off, for me, but YMMV.