I think the design of interfaces is a difficult and subtle art. You have to have a very refined understanding of both of the layers being interfaced, so you can understand where the boundary should go and what shape it should have so concepts don’t get split across layers. You also need to have a keen understanding of how the humans using the interface will behave in the future, which is really hard and often impossible. I think that’s why interfaces tend to evolve over time along with the tech, because assumptions built into them were either incorrect, or became incorrect (or just confusing) as the technical landscape shifts around them.
Speaking of shifting landscapes, I think one of the fundamental practices of engineering is prototyping: building a thing that does what you think you want, even if it’s janky or unscalable or has an insane cyclomatic complexity or w/e. Sometimes building the janky version can lead to insights into how an improved version can be made; insights that would be very difficult or impossible to predict if one tried to build the perfect version on the first go.
This causes some problems in corporate development, because the chance to learn from a model and iterate on it directly is so rare. The vast majority of the time (IME), as soon as the janky version fulfills the client’s list, it moves into production and the improvements are, if not written off entirely, put on the backlog of tasks that will never be more important than building out the next new thing. It’s still possible to iterate ideas in future new projects, it happens all the time, but it’s different than building one thing and refining it in an iterative development cycle over a long term.
I think the design of interfaces is a difficult and subtle art. You have to have a very refined understanding of both of the layers being interfaced, so you can understand where the boundary should go and what shape it should have so concepts don’t get split across layers. You also need to have a keen understanding of how the humans using the interface will behave in the future, which is really hard and often impossible. I think that’s why interfaces tend to evolve over time along with the tech, because assumptions built into them were either incorrect, or became incorrect (or just confusing) as the technical landscape shifts around them.
Speaking of shifting landscapes, I think one of the fundamental practices of engineering is prototyping: building a thing that does what you think you want, even if it’s janky or unscalable or has an insane cyclomatic complexity or w/e. Sometimes building the janky version can lead to insights into how an improved version can be made; insights that would be very difficult or impossible to predict if one tried to build the perfect version on the first go.
This causes some problems in corporate development, because the chance to learn from a model and iterate on it directly is so rare. The vast majority of the time (IME), as soon as the janky version fulfills the client’s list, it moves into production and the improvements are, if not written off entirely, put on the backlog of tasks that will never be more important than building out the next new thing. It’s still possible to iterate ideas in future new projects, it happens all the time, but it’s different than building one thing and refining it in an iterative development cycle over a long term.