Hacker News Reader

Comment by JeanMarcS | Hacker News Reader

Oh boy, I’ve seen it to often... « So let’s start with the UI and where things are gonna be » « But shouldn’t we be sure that the content fits the demand first » « No. You know customers, if they don’t see something very visual, they think we are not working, so start with UI »

And in the end, you find that not only you had to twist your server code to fit the « visual needs », but you still changed the UI so many times that your project explodes the deadlines.

I have a name for project like that, the name of a client I had from back in the days when I was younger.

Now, I try to run away from that kind of projects (not always succeeding, in 2015 I joined a project like that and loose a year and a half producing jquery shit)

View on HN

I've observed something a little bit like this on some long-running internal business tools, where the "GUI-first development" approach also causes problems.

Your data model ends up resembling the entry-forms and wizard-steps proposed by managers, rather than capturing the underlying ideas of the bounded-context.

Since having it look right is so important, you also get a lot of business logic which lives closer to the GUI than it should. This makes it difficult to automate things because certain rules are soft-enforced by the order and steps of the interface and JS widgets rather than by anything explicit in code.

The unhappy feedback loop continues as you get a system which can only be tested through the GUI, and it's no longer clear what parts of the app are deliberate rules versus incidental limitations.

You've essentially described my interaction with dozens of agencies, where all projects are initially design-led and passed to the developers.

It's funny how everything a (good) developer builds will match a written requirement, but often a design won't accurately match a set of functional requirements, and typically the non-functional requirements are nowhere to be found because, you know, we're agile and we don't have time to write pages of non-functional requirements to accurately scope our work...

This sounds like a real case of the client knows everything better, and only hired you so they could let you know they are better at your job.

If only we could get those years of wasted development back.

On the flip side UIs are a very effective way to demonstrate ideas to users, so long as you keep them lightweight. If you want quick feedback on requirements build a UI.

That scene is too familiar. Trying to get a client to understand incremental delivery is probably more difficult than enforcing the practice on a team.

Reply on news.ycombinator.com