6 ms·
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 proble
by BiteCode_dev 4y ago
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.
- MrLeap 4y agoA 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.
- BiteCode_dev 4y agoIf you have demo meetings that matter, you likely have a designer, in that case the UI won't be ugly.
- lightbendover 4y agoDemo 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.
- BiteCode_dev 4y agodemo 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.
- lightbendover 4y agoAll of those things can be done through other mechanisms without distracting engineers with a dog and pony show.
- jugg1es 4y agoI 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.
- BiteCode_dev 4y agoI 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.
- sdze 4y agoI coach Product Owners the same way when trying to create a backlog.
- retrocryptid 4y agoI 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.
- tabtab 4y agoA 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.
- cestith 4y agoFor 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.
- retrocryptid 4y agoGood point. I was interpreting "UI" as "GUI".
- BiteCode_dev 4y agoExactly. A web api, a CLI... It doesn't have to be graphical.
- skybrian 4y agoXP 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.
- beached_whale 4y agoThis 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.