4 ms·

This is why the API should ALWAYS at least have a first pass before any coding is done. Changing how things look and feel after the fact? Not an issue. Chang

This is why the API should ALWAYS at least have a first pass before any coding is done. Changing how things look and feel after the fact? Not an issue. Changing the underlying data structures? Holy shit, kill me now. Hell, if your API is solid (and you're using actual restful calls) then you should be able to completely decouple UI coding, business logic, and data management. Of course with the modern love of AGILE (see rapid prototyping) people wonder why so much rework is always needed because that's simply not the case.

nicoslepicos 11y ago
Yes. 100% this. The API / object modeling is nearly the spec and the main thing to nail down. On past projects we've used Apiary as a pretty good option for getting a nailed down API Spec before any coding is done: https://apiary.io/ https://apiary.io/. I think here more out of the box best practices around APIs will make these API specing tools even more effective. I know what you mean about changing underlying data structures too. There are ways to fix the issues after the fact. E.g. wrapping existing concepts in other ones, and then gracefully deprecating the old ones. But, it definitely creates all sort of weird tensions with customers that are using the old concepts.
nostrademons 11y ago
This doesn't actually work unless the "first pass" on the API consists of using it to build actual programs, preferably multiple ones of wildly different genres. Otherwise, you end up with an API that is a beautifully designed ice crystal, perfect for the use case that the founder envisioned and generally useless & frustrating for real-world customers. That's exactly the type of conceptual debt that the article is talking about.