[hitchstory]

Im not sure quite why you feel you always need to write code before sussing out what an API or UI should look like but it seems like a very expensive habit to me.

What happens when you then show it to stakeholders (e.g. other teams consuming your API, customers or UX people) or and they tell you to change it again?

Rewrite everything again?

Thats gonna be reaaaaaaaalllly labor intensive and could damage your code base too.

Im equally perplexed about why people dont try to build top down. It's one of those few things in programming that always makes sense regardless of circumstance.

[Izkata]

> What happens when you then show it to stakeholders (e.g. other teams consuming your API, customers or UX people) or and they tell you to change it again?

> Rewrite everything again?

> Thats gonna be reaaaaaaaalllly labor intensive and could damage your code base too.

Why would I do that? Only the thing they have issue with would need to be changed, it wouldn't take any longer than another way of doing it.

You seem to have forgotten what I said, something needs to exist for me to work with. Well, in this "stakeholders want something changed", something exists. It's not a rewrite from scratch.

[hitchstory]

>Why would I do that?

If you change the spec (e.g. changing the contract on a REST API), you will probably need to consult to make sure it aligns with everybody's expectations. Does the team calling it even have the customer ID you've just decided to require on, say, this new endpoint?

>You seem to have forgotten what I said, something needs to exist for me to work with.

No. I'm assuming here that a code base exists and that you are mostly (if not 100%) familiar with it.

[Izkata]

So what's the problem? You seem to have gone back on the part I quoted in my previous comment.

[simonw]

If Izkata is anything like me they write code as part of their exploratory design process with no intention of showing it to anyone else until they've iterated their way to a design that they like.