4 ms·

This pretty much exactly describes my strategy to ship better code faster. Especially the “top down” approach: I’m actually kind of surprised there isn’t like a

This pretty much exactly describes my strategy to ship better code faster. Especially the “top down” approach: I’m actually kind of surprised there isn’t like a “UI first” or “UI Driven Development” manifesto like w TDD or BDD. Putting a non functional UI in front of stakeholders quickly often results in better requirements gathering and early refinement that would be more costly later in the cycle.

deleted 1y ago
[deleted]
zwnow 1y ago
Why not build a simple functional UI, its not a huge time sink between non functional and functional (as long as kept simple)
- vinibrito 1y ago
  Well, most of the times people I worked with preferred something earlier even if just by a few days that they could see and comment on. Maybe that is why for him too.
- shireboy 1y ago
  Well, sometimes I will, but for example take a simple list+form ontop of a database. Instead of building the UI and the database and then showing the stakeholder, who adds/renames fields, changes relationships etc. I will intentionally build just the UI not wired up to database. Sometimes just to an in-memory store or nothing. Then, _after_ the stakeholder is somewhat happy with the UI, I "bake" things like a service or data layer, etc. This way the changes the stakeholder inevitably has up front have less of an impact.
gavmor 1y ago
I call it "outside in", but sometimes like to de-risk a lower level component before investing in the UI.
whizzter 1y ago
I think at that point it's almost better to come with paper printouts for 2 reasons. 1: Tacticale/shareable/paintable in a physical meeting 2: It drives home that it's a sketch, with bad customers a visible UI so easily hides the enormous amounts of complexity that can sometimes be under a "simple" UI and make it hard to educate them as to why the UI sketch one did in an hour or two then needs 1500 hours of engineering to become a functioning system.

deleted 1y ago

[deleted]

zwnow 1y ago

Why not build a simple functional UI, its not a huge time sink between non functional and functional (as long as kept simple)

vinibrito 1y ago
Well, most of the times people I worked with preferred something earlier even if just by a few days that they could see and comment on. Maybe that is why for him too.
shireboy 1y ago
Well, sometimes I will, but for example take a simple list+form ontop of a database. Instead of building the UI and the database and then showing the stakeholder, who adds/renames fields, changes relationships etc. I will intentionally build just the UI not wired up to database. Sometimes just to an in-memory store or nothing. Then, _after_ the stakeholder is somewhat happy with the UI, I "bake" things like a service or data layer, etc. This way the changes the stakeholder inevitably has up front have less of an impact.

gavmor 1y ago

I call it "outside in", but sometimes like to de-risk a lower level component before investing in the UI.

whizzter 1y ago

I think at that point it's almost better to come with paper printouts for 2 reasons. 1: Tacticale/shareable/paintable in a physical meeting 2: It drives home that it's a sketch, with bad customers a visible UI so easily hides the enormous amounts of complexity that can sometimes be under a "simple" UI and make it hard to educate them as to why the UI sketch one did in an hour or two then needs 1500 hours of engineering to become a functioning system.