Hacker News Reader

Hacker News

Comment by BiteCode_dev | Hacker News Reader

Full thread

BiteCode_dev

I usually champion the "let's start with the UI" state of mind in every company I go.

This has several benefits:

- it forces to confront reality of the problem and field

- you have to talk to people, and understand their needs

- you almost get your backend public API out of it for free

After that, you don't really need to do full top down, you can split in subsystems, and works on small parts of those subsystems.

It doesn't have to be a good looking or sophisticated UI. It can be a ugly, as long as it's practical and validated by the end user.

But this works only well the if the problem can be well defined and you know how to solve it.

If you need to figure it out, top down doesn't work as well.

View on HN

A downside to this is that some types of stakeholders lament the apparent glacial state of progress backfilling a UI with functionality.

A tick/tock of UI/functionality keeps those people from getting depressed during demo meetings.

If you have demo meetings that matter, you likely have a designer, in that case the UI won't be ugly.

Demo meetings that matter, now that's an anti-pattern if I've ever heard one. Only UI work makes for a snazzy demo, anything else will bore stakeholders to tears (and you of course need stakeholders if the meeting matters). The backend can be completely mocked out and stakeholders wouldn't even realize. All demos do is bely progress and make milestones seem closer or farther away than reality. The only "demo" that matters is the actual product launch.

demo meeting matters for several things:

- reassuring the people that pay the bill

- get PR feedback

- give a concrete objective with a deadline to the team

But like a lot of things, it's not useful for what most people think it's useful.

All of those things can be done through other mechanisms without distracting engineers with a dog and pony show.

I have always had great success when systems are designed from the UI first. It really helps you break a new business case down to the point where the backend code just starts writing itself.

I suspect you are coming from a design background because people who have never built a UI before are always very suspicious of this suggestion.

I don't come from a design background but my father drilled into my skull that nobody cared about my beautiful skills at work. They cared about their problems and if I could solve them.

Coding just happen to be a mean to solve their problems, but they don't understand code, and I don't understand their problem.

After a lot of frustrating client/dev interactions, I came to read "don't make me think" from Steve Krug. I realized the UI was the only language I shared with my customers to start a meaningful discussion.

This turned out to work well, and got me paid, so I sticked to it.

This is how I start with libraries. How do I want to use it, and start with some code that will eventually compile. It acts as an integration test too. But this starts to expose issues earlier with my understanding. Then if the interface doesn't work, it's easier to fix earlier.

I know it's passe, but I generally like to start with a set of requirements first. In the old days, when we were doing XP instead of agile, we didn't feel the pressure to "code something, anything." Now, unless I check in a couple thousand lines of code per day people think I'm slacking.

But... not trying to say "build the UI first" is a bad choice if it works for you. I do mostly backend work on "high trust" transactions, so I tend to look at the API first and see if it matches the requirements i have at the time.

A good many times the customer doesn't spot important issues until they see it in a UI, preferably interactive. The design process is done best with a combination of formal written requirements and mockups/demos.

For some applications, like an API-driven backend made to serve other applications, you can consider that the API itself really is your UI. It's how your users interface to your code. Your users just happen to be other developers whose code had it's own UI too, maybe a text or graphical one or maybe another API.

Good point. I was interpreting "UI" as "GUI".

Exactly. A web api, a CLI... It doesn't have to be graphical.

XP as I remember it was about implementing one customer-relevant feature at a time. This isn’t too-down or bottom-up, it’s doing a thin vertical slice. There shouldn’t be code that isn’t used or buttons that don’t work.

We did work from a designer’s mockup, though.

I don't think that's XP.

Trouble is, how do you get this set of requirements?

The UI is the answer to that.

The UI [GUI, API, CLI, etc] is a statement in the "solution domain." By "requirements," I mean a problem statement.

"A form with three text inputs labeled street, state and zip" is solution while "the system should allow the user to specify an address" is a problem statement. (And ideally it should be more detailed with respect to its context: "The system should allow a user to specify an address associated with a delivery record, associated with the user's id.")

The problem is generally poorly perceived and expressed by the client, and badly understood by the dev.

So the UI is the best road to build one in collaboration with the client.

I coach Product Owners the same way when trying to create a backlog.

Reply on news.ycombinator.com