You make a good point. I didn't mean to imply you should always defer your frontend decisions or that the frontend is much more dangerous to get locked into (apologies if that wasn't clear).
I agree with you also. It seems much more dangerous to get locked into a bad data architecture. However, it may be a moot point because once you get far enough down the road, most businesses are going to resist changing either one. Unless there's a big initiative, most people don't want to go back and make far reaching, risky changes.
In the end, it seems as though it's a balance (the life of a software engineer). I don't think you want to near completion of a frontend without thinking about the backend. Sketches, rough designs, and prototypes should be enough to start thinking about the business logic.
Instead of weaving Bootstrap into my frontend, I could've just started building out a UI with HTML and very limited CSS. It would've looked terrible, but it would've allowed me to start understanding use cases and how they're supported with business logic. By keeping it simple, it's cheap to throwaway if I realize we should build the frontend with React or something else.
I think we should combat the sunk costs fallacy instead of engaging in it, but yeah, sketching can definitely give you some idea.
Still, what should you be showing to your friends/coworkers while hiding from those horrible business people? A prototype of an API server, or a mock of an interface, with the navigations but with static/random data and no backend calls at all?
To me, the latter is just a better version of design-mocking/wireframing software, focused less on the look and more on the specifics of the interaction (vs simple links from slide to slide)
But I totally get where you're coming from, it's easy to feel attached, and the business just doesn't get it and grabs on to the unoptimized prototype like it's their firstborn.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You make a good point. I didn't mean to imply you should always defer your frontend decisions or that the frontend is much more dangerous to get locked into (apologies if that wasn't clear).
I agree with you also. It seems much more dangerous to get locked into a bad data architecture. However, it may be a moot point because once you get far enough down the road, most businesses are going to resist changing either one. Unless there's a big initiative, most people don't want to go back and make far reaching, risky changes.
In the end, it seems as though it's a balance (the life of a software engineer). I don't think you want to near completion of a frontend without thinking about the backend. Sketches, rough designs, and prototypes should be enough to start thinking about the business logic.
Instead of weaving Bootstrap into my frontend, I could've just started building out a UI with HTML and very limited CSS. It would've looked terrible, but it would've allowed me to start understanding use cases and how they're supported with business logic. By keeping it simple, it's cheap to throwaway if I realize we should build the frontend with React or something else.
What are your thoughts?
I think we should combat the sunk costs fallacy instead of engaging in it, but yeah, sketching can definitely give you some idea.
Still, what should you be showing to your friends/coworkers while hiding from those horrible business people? A prototype of an API server, or a mock of an interface, with the navigations but with static/random data and no backend calls at all?
To me, the latter is just a better version of design-mocking/wireframing software, focused less on the look and more on the specifics of the interaction (vs simple links from slide to slide)
But I totally get where you're coming from, it's easy to feel attached, and the business just doesn't get it and grabs on to the unoptimized prototype like it's their firstborn.