Thanks for commenting!

> There doesn't seem to be a clear answer on what extend of
> upfront-planing is good or bad, even if there are complete bookshelves
> written about that.

Very true :) I suspect it's because both planning and not-planning can
work well if you have the right personalities. A team full of organized
people will get better results with clear plans, whereas a team full of
disorganized people will get better results without plans. We are having
difficulties because we have both.

You can witness this even in leisure activities. Some people want to
plan ahead which museum to visit or when to have dinner, others don't
see the point. Either approach works as long as people get along.

> Still taking your list from above, I see no way how to reasonable start
> on one part, since they are interdependent. Before I could write a
> client, I would need at least a minimal server-side API against which to
> write.
I thought the clients and server can (and should) co-evolve constantly.

It's true that the protocol needs to be chosen first. As you can tell,
I've been so impressed by GraphQL that I'm skeptical there could be a
better alternative, but I'll gladly look at any other suggestions. What
I can say is that coming from a REST background, it feels like being
transported into the future. The tedious, error-prone stuff is automated
or unnecessary and you can concentrate on thinking about the data (what
Fred Brooks would call "intrinsic complexity").

I got inspired to write GraphQL tools for Scheme as fast as I can, so
hopefully it'll be possible to run a Scheme server soon. John is helping
out designing a S-expression syntax for queries and schemas.

I like the rest of your suggestions. I'm sure we can find a way of
working that suits us if we can agree on the API protocol.

> I personally would also prefer to first work on one client and
> only start others with one end-to-end piece working. For sure this will
> lead to follow-up discussion as how much wiggle room that first client
> leaves for the others, but the alternatives - the first one needs be
> correct at first shot or all of them can just be completely different -
> seem to be worse.

If we choose GraphQL, it solves this problem handily because the API
response format is completely client-dictated. (The server merely
specifies an object model, and the possible queries that can be
performed. Whenever it makes a query, the client specifies exactly which
fields it wants from the objects returned by the query. That way the API
designer doesn't need to worry about favoring one client at the expense
of others.)