Timeline for Generally speaking, is it better to make all the functional parts or get UI working first - or a mix of the two?
Current License: CC BY-SA 3.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2020 at 0:48 | comment | added | James | Yes this is how good dev is anyway really (in most cases). Often design or coding front or back separately leads to revealing design flaws or missed requirements when you start to later code the other side. E.g. do a page at a time (back end/controller/services etc, front end to show it). Then you can show case login/reg/some page is done which shows progress for a specific page. They see progress, you are 99% done with that page. | |
| Aug 7, 2014 at 8:49 | audit | First posts | |||
| Aug 7, 2014 at 9:47 | |||||
| Jul 29, 2014 at 14:23 | comment | added | Kathy | @MichaelT You are my hero for that link. Thank you! :) | |
| Jul 29, 2014 at 4:24 | comment | added | Daveo | I would tend to disagree with this 'Don't make the Demo look Done' it seems like this approach is more about managing customer expectations then what is the most efficient use of resources. Yes it is important to manage expectations but this still be done in other ways | |
| Jul 29, 2014 at 3:31 | comment | added | user28988 | Comment thread's starting to get a tad long. Consider taking this discussion to Software Engineering Chat. | |
| Jul 29, 2014 at 2:27 | comment | added | Aaronaught | @Graham: It depends on who you're working for and what their management is like. It's more typical of non-technical management, and especially non-technical management that loves deadlines and is accustomed to seeing half-finished products ship. | |
| Jul 29, 2014 at 1:38 | comment | added | user40980 | @Kathy from the math world, you may be interested in chrisstucchio.com/blog/2014/… which leads to graphs with less exactitude (and thus less importance on the raw numbers and more about the shape / context). | |
| Jul 29, 2014 at 1:35 | comment | added | user40980 | @Alexander in my expansion of "Don't make the Demo look Done" there are some anecdotes in there linking to this talk about how the flash presentation given by Microsoft for Vista lead to developers thinking things were more final than they were, and even the executives thought they were seeing real things. Its about setting the expectations and some people have difficulty understanding the difference between the blue print and the final product - if the facade looks done, the rest is done too... right? (or so the expectation is) | |
| Jul 29, 2014 at 1:29 | history | edited | user40980 | CC BY-SA 3.0 | Add "Don't make the Demo look Done" |
| Jul 28, 2014 at 22:49 | comment | added | user40980 | @djechlin you are welcome to that. Many times I have dealt with people who think that when it looks done, its 90% done and everything else should be done Real Soon Now (and any estimates that programmers give to the contrary are them just padding numbers and slacking off). If you have been able to avoid these business users and clients, you have been lucky and I hope that your luck continues. There are indeed issues with iterations of feature requests based on the UI that should be addressed too, but scope and feature changes on that first 'it looks done' can spiral with it never getting done. | |
| Jul 28, 2014 at 22:38 | comment | added | djechlin | This answer is still wrng. You seriously think there's a bigger risk of a perfect UI that looks too good, over a UI that invites a zillion feature requests small and large that reveal the original spec was all wrng? | |
| Jul 28, 2014 at 22:30 | comment | added | user40980 | @Two-BitAlchemist thank you - I must have had the wrong thing in my clipboard when I worked added that and didn't realize what I was pasting (multitasking and context switches of the brain isn't always thread safe). | |
| Jul 28, 2014 at 18:07 | comment | added | Kathy | +1 for Napkin L&F. That will surely be in my future. :) | |
| S Jul 28, 2014 at 16:10 | history | suggested | Billy Mailman | CC BY-SA 3.0 | Link was pointed at entirely the wrong place. Also, had a typo in the link text. |
| Jul 28, 2014 at 16:02 | comment | added | Two-Bit Alchemist | I guess you were trying to link to this? That link in your answer points to a tag on sqa.SE! | |
| Jul 28, 2014 at 15:54 | review | Suggested edits | |||
| S Jul 28, 2014 at 16:10 | |||||
| Jul 28, 2014 at 13:24 | comment | added | GHP | I've been designing UI's for the bulk of my programming career and NOT ONCE have I had a client assume that a prototype UI meant that the software was 'almost done'. It sounds to me like the presenters of wireframe UI's are not doing a good job explaining the wireframes up front if the clients are somehow confused into thinking that the project is almost done. | |
| Jul 28, 2014 at 9:59 | vote | accept | RobotHumans | ||
| Jul 28, 2014 at 5:31 | comment | added | Alexander | @MichaelT - looks good! Also, on a bit of a tangent, I've found it helpful to use analogies when setting expectations and explaining complex things to business people. Such as, mockups and requirements are to programming software, what concept drawings and blueprints are to constructing a building. Nobody (in their right mind :) expects a building to be nearly ready to open when there's only a blueprint in front of them! | |
| Jul 28, 2014 at 1:24 | history | edited | user40980 | CC BY-SA 3.0 | added 1483 characters in body |
| Jul 28, 2014 at 1:16 | comment | added | djechlin | UI couples to and informs feature development. Therefore UI is highest risk and changes the requirements as it develops. This is true for technical risk in the backend ("whoops there's no algorithm to do this fast enough for what the user requires") but in practice far far less. | |
| Jul 28, 2014 at 0:30 | comment | added | user40980 | @Alexander I've expended/reworded the bit on builds to make it a bit more clear what i was trying to get at. Do you have any other suggestions? | |
| Jul 28, 2014 at 0:29 | history | edited | user40980 | CC BY-SA 3.0 | added 347 characters in body |
| Jul 28, 2014 at 0:19 | comment | added | Alexander | @radarbob Excellent point. I think "Deliver incremental builds and make sure you're making what the client wants" describes an agile approach, as work is typically done "bit" by "bit" (i.e. feature by feature, issue by issue, etc...) without presupposing traditionally agile things like sprints, CI, TDD, etc... | |
| Jul 27, 2014 at 22:41 | comment | added | radarbob | +1 to @Alexander comment. But an Agile approach, at least, to developing functional bits. And a "bit" does not have to mean a complete, fully functional, screen. | |
| Jul 27, 2014 at 22:09 | comment | added | ragol | In case you did not see an expert answer to that video, here it is: youtu.be/B7MIJP90biM | |
| Jul 27, 2014 at 19:38 | comment | added | RobotHumans | @Alexander - you made me smile quite a bit with that one. | |
| Jul 27, 2014 at 19:14 | comment | added | Alexander | Indeed, dealing with "not so technically inclined" business people, there can be some misconceptions. youtu.be/BKorP55Aqvg | |
| Jul 27, 2014 at 18:35 | comment | added | user40980 | @Alexander Agile helps in this case, but isn't essential. Waterfall can have (deliverable) milestones and customers can be very disappointed at seeing the "it looks done, why are there 3 more mile stones that take just as long?" FWIW, I've had instances where the business user thought it was done because of the screen shot + ms paint in the tech design (waterfall shop) looked good. | |
| Jul 27, 2014 at 18:32 | comment | added | Alexander | Sounds like you're proposing some kind of agile methodology... :) | |
| Jul 27, 2014 at 13:43 | history | answered | user40980 | CC BY-SA 3.0 |