I was afraid this would be yet another misrepresentation of Last Responsible Moment as Last Possible Moment and abuse of YAGNI, but it was a practical, actionable solution to reaching for numerous front end dependencies before devising the business logic.
However ⚠️: What do you say to the following?
The UI is the product, everything else is just the crap supporting it
- Probably some APPL dude
Is it really often that you correctly know what business logic you need without a UI in front of you? Is it not much more dangerous to get locked into wrong data architecture and process flows than into a simple CSS library?
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.
I was afraid this would be yet another misrepresentation of Last Responsible Moment as Last Possible Moment and abuse of YAGNI, but it was a practical, actionable solution to reaching for numerous front end dependencies before devising the business logic.
However ⚠️: What do you say to the following?
Is it really often that you correctly know what business logic you need without a UI in front of you? Is it not much more dangerous to get locked into wrong data architecture and process flows than into a simple CSS library?
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.