A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…
I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake.
I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works.
I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).