5 ms·
> You want simplicity where it benefits the user, which often requires increased complexity for the developer. My analogy for this is how complex modern cars ar
by csours 3y ago
> You want simplicity where it benefits the user, which often requires increased complexity for the developer. My analogy for this is how complex modern cars are, but you push a button to “start” them.
Developers are users too. Everyone needs good user experience.
Modern cars are complex, assembly lines are complex, engineering is complex, but most assembly jobs are super simple.
- midasuni 3y agoI had a hire car with a “push button” thing last week. Push the button nothing happens Read the manual Press the clutch and push, stoop nothing Then you have to push break, clutch and push the button. But you have to push the button for several seconds. Same with the handbrake, it’s a button, sometimes on, sometimes off. Maybe it will stay on when you’re parked, who knows. Give me a real key and real handbrake any day, that’s far simpler and gives me far more control.
- reidjs 3y agoI had this same thought after reading that line. I started thinking about where the complexity should live, if not with the developers. My conclusion is that it should live with whoever has the most 'skin in the game,' or the largest stakeholder of the enterprise. So, the CTO, CEO, Founder, Director, etc should "own" the complexity?
- csours 3y agoIt's not complexity per se. Some things will always be complex. It's about continuous improvement of things like documentation and observability - "non functional" stuff.
- RetroTechie 3y agoSome complexity is artificially introduced - on purpose, by the abstraction itself. Imho abstractions should be simple enough that whatever complexity its implementation introduces, is manageable by its users & developers. Quite a few APIs exist which are complex enough that hardly anyone (developer or user) has a handle on existing implementation. Imho such an API overshoots its goal: it abstracts too much, and/or too high level, to the point where understanding what's between API & underlying hardware, becomes impossible for 1 human. Never mind understand underlying hardware (or write software that uses the API efficiently), because API creates a target that's alien compared to hw it runs on. That doesn't make sense! Cut the abstraction down to a manageable degree of (added!) complexity.
- bartread 3y agoI don't think that scales: a lot of the complexity is in the detail. It's pretty hard for it to meaningfully live with someone whose job is all about higher level concerns and bigger, more forward-looking moves.
- bartread 3y ago> Developers are users too. But not generally the users of the systems that are being built. Those are the people you need to think about. Sometimes they will be other developers, but more often they'll be end users of some sort or another. And, even as a developer, I don't want your leaky abstractions and complexities bleeding through your service API endpoints all the time.
- csours 3y agoDevelopers are users of the API specification, etc