6 ms·

It feels like problem with these aren't the ideas, rather the "let's just" approach/expectation in front of them. For instance "Let's just add an API." I think

by ajcp 2y ago

It feels like problem with these aren't the ideas, rather the "let's just" approach/expectation in front of them. For instance "Let's just add an API." I think the approach to an API as "just" a feature to your product will be about as successful as saying "let's just add a UI". To implement a successful UI one needs to be thoughtful, thorough, and bring in people who specialize in it. Why should any other interface for your product be any different? It's not that it's a bad, or good, idea, rather one that shouldn't "just" be done.

vasco 2y ago
Most professional advice is like relationship advice, people extrapolate something that went wrong for them into general cases but that rarely directly applies to someone who is not you in that very similar situation. And the advice that seems to work consistently gets so generic that is almost useless. Something like "be thoughtful, try to do the right thing and reflect back to see how it went" doesn't write blog posts or sells books!
gmuslera 2y ago
Cargo cults around these system ideas are dangerous. The idea may be good, but without understanding what really makes them work or not is dangerous.
- fullstackchris 2y ago
  Dangerous? In the sense a bad API is dangerous? If so then I've been in danger consuming catastrophic APIs for at least a decade now
justin_oaks 2y ago
Exactly. There's no "just" when you're adding an API. APIs require a lot of work and complexity to do right: APIs need to be well-designed or the client may need to make multiple API calls when one should suffice. Or the API could be confusing and people will call it wrong or fail to use it at all. APIs require authentication and authorization. This means setting up OAuth2 or at least having a secure API token generation, storage, and validation. APIs need handle data securely or you'll leak data you shouldn't, or allow modification you shouldn't. APIs need to be performant or you database may be crushed under the load. This may involve caching which then adds the complexity of cache invalidation and other servers/processes to support caching. APIs need to be rate-limited or sloppy clients will hammer your API. APIs require thorough documentation or they're useless. You may even have to add SDKs (libraries for different programming languages) to make it easier for people to use the API. APIs need good error messages or users who are getting started will not know why their calls are failing.
- eddythompson80 2y ago
  lol, I can already hear the responses of plenty of managers/management I worked with to these points. > APIs need to be well-designed or the client may need to make multiple API calls when one should suffice. Or the API could be confusing and people will call it wrong or fail to use it at all. That's fine. It's a first iteration we can change it later if people complain. Lets get something out there and iterate. > APIs require authentication and authorization. Lets not worry about authorization/permissions. It's just one key or whatever account they use to log in with now. > APIs need handle data securely or you'll leak data you shouldn't, or allow modification you shouldn't. You're saying you don't know how to do that? > APIs need to be rate-limited or sloppy clients will hammer your API. Either "Lets worry about that later when it happens" or "Here is the first github link from a google result for 'api rate limit open source free'. Lets use that" > APIs require thorough documentation or they're useless. Either "We need to have the API first, docs, clis, etc could come later after we have gauged the usage or had asks for them. We can handhold the customers asking for them for now." or "here is a github project that autogenerates docs, SKDs and clis from an OpenAPI spec" > APIs need good error messages or users who are getting started will not know why their calls are failing. You're saying you don't know how to do that? "It doesn't have to be perfect. We have customers who are asking for it and to win them we need to implement something then we can work with them to improve it. Otherwise we will lose them"™
  - liontwist 2y ago
    Yep, helps a lot when your management is in the domain. Phased implementation isn’t the worst idea, they just have to be committed to ending the experiment or seeing it through.
  - 9dev 2y ago
    Then again, these answers are valid. Your fancy API documentation will only be skimmed, nobody is going to notice the elaborate and elegant URI design or the discussion around whether to use PUT or PATCH, and the super-secure token mechanism you come up with will be written on a sheet of paper in the office. Most projects are far too fluid in their shape to warrant a proper design up-front anyway.
nswanberg 2y ago
Yegge wrote about the business idea version of this as "Shit's Easy Syndrome": https://steve-yegge.blogspot.com/2009/04/have-you-ever-legalized-marijuana.html https://steve-yegge.blogspot.com/2009/04/have-you-ever-legal... It'd have been delightfully ironic had either of these Steves concluded their essays with a named methodology to "just" apply whenever faced with these "let's just" situations but alas...
jabroni_salad 2y ago
I am pretty sure presales as a career exists solely because of the word 'just'. We have to make sure they wont get spooked when we start lifting the rest of the iceberg out of the water.
aprilthird2021 2y ago
Yes, and a very well designed API can be the foundation of and moat for a successful business. Stripe is one of the best examples. Even as hundreds of copycats pop up, their excellent API design and the trust devs have in them to nail the next API design, means they can continue to expand into other financial products with ease.
btilly 2y ago
At a previous employer we had a rule. The only person allowed to say, "just", was the developer responsible for actually making it work. Another developer who said it, just volunteered themselves. It was a rule that worked well for us.
- gdsdfe 2y ago
  That's a good one!
- jrs235 2y ago
  Needs to also be for "that's easy"...
- sharpy 2y ago
  I am totally going to advocate for this at my workplace. I myself am guilty of it - not saying "just", but questioning people's estimates based on my limited understanding of the research they had to do to come up with the estimates in the first place.
  - ffsm8 2y ago
    It sounds pretty toxic if you're not allowed to even question other people's estimates. IME that's a large part of Grooming/refinements
    - dambi0 2y ago
      Aiming for an environment where uniformed challenges to estimates are discouraged is an entirely different thing to forbidding any challenges to estimates.
- BlarfMcFlarf 2y ago
  Punishing people with more work doesn’t make sense in a well run organization. Work is continuous and more work only affects the backlog, not the actual developer’s life or experience.
  - 2y ago
karmakaze 2y ago
Yes exactly. The article would be much better positioned as What it actually takes to make systems ideas "just work". Then it isn't about whether it can or can't but rather how it succeeds or fails. Having details about what it takes then stops people from saying "just" because they don't know what they're talking about. But I pretty much agree 100% about DSLs, it's an unnecessary/cute complication. The only people who should be allowed to make them should be ones who have made a successful programming language and updated it to deal with all their mistakes or a 2nd version/2nd language, and still got many things wrong.
deleted 2y ago
[deleted]
fosk 2y ago
Furthermore, API is a product that needs its own lifecycle to be versioned, decommissioned, continuously improved. Often I see developers creating new APIs ad-hoc all the time instead of curating and enhancing the one they already have.

by ajcp 2y ago

vasco 2y ago

Most professional advice is like relationship advice, people extrapolate something that went wrong for them into general cases but that rarely directly applies to someone who is not you in that very similar situation. And the advice that seems to work consistently gets so generic that is almost useless. Something like "be thoughtful, try to do the right thing and reflect back to see how it went" doesn't write blog posts or sells books!

gmuslera 2y ago

Cargo cults around these system ideas are dangerous. The idea may be good, but without understanding what really makes them work or not is dangerous.

fullstackchris 2y ago
Dangerous? In the sense a bad API is dangerous? If so then I've been in danger consuming catastrophic APIs for at least a decade now

justin_oaks 2y ago

Exactly. There's no "just" when you're adding an API. APIs require a lot of work and complexity to do right: APIs need to be well-designed or the client may need to make multiple API calls when one should suffice. Or the API could be confusing and people will call it wrong or fail to use it at all. APIs require authentication and authorization. This means setting up OAuth2 or at least having a secure API token generation, storage, and validation. APIs need handle data securely or you'll leak data you shouldn't, or allow modification you shouldn't. APIs need to be performant or you database may be crushed under the load. This may involve caching which then adds the complexity of cache invalidation and other servers/processes to support caching. APIs need to be rate-limited or sloppy clients will hammer your API. APIs require thorough documentation or they're useless. You may even have to add SDKs (libraries for different programming languages) to make it easier for people to use the API. APIs need good error messages or users who are getting started will not know why their calls are failing.

eddythompson80 2y ago
lol, I can already hear the responses of plenty of managers/management I worked with to these points. > APIs need to be well-designed or the client may need to make multiple API calls when one should suffice. Or the API could be confusing and people will call it wrong or fail to use it at all. That's fine. It's a first iteration we can change it later if people complain. Lets get something out there and iterate. > APIs require authentication and authorization. Lets not worry about authorization/permissions. It's just one key or whatever account they use to log in with now. > APIs need handle data securely or you'll leak data you shouldn't, or allow modification you shouldn't. You're saying you don't know how to do that? > APIs need to be rate-limited or sloppy clients will hammer your API. Either "Lets worry about that later when it happens" or "Here is the first github link from a google result for 'api rate limit open source free'. Lets use that" > APIs require thorough documentation or they're useless. Either "We need to have the API first, docs, clis, etc could come later after we have gauged the usage or had asks for them. We can handhold the customers asking for them for now." or "here is a github project that autogenerates docs, SKDs and clis from an OpenAPI spec" > APIs need good error messages or users who are getting started will not know why their calls are failing. You're saying you don't know how to do that? "It doesn't have to be perfect. We have customers who are asking for it and to win them we need to implement something then we can work with them to improve it. Otherwise we will lose them"™
- liontwist 2y ago
  Yep, helps a lot when your management is in the domain. Phased implementation isn’t the worst idea, they just have to be committed to ending the experiment or seeing it through.
- 9dev 2y ago
  Then again, these answers are valid. Your fancy API documentation will only be skimmed, nobody is going to notice the elaborate and elegant URI design or the discussion around whether to use PUT or PATCH, and the super-secure token mechanism you come up with will be written on a sheet of paper in the office. Most projects are far too fluid in their shape to warrant a proper design up-front anyway.

nswanberg 2y ago

Yegge wrote about the business idea version of this as "Shit's Easy Syndrome": https://steve-yegge.blogspot.com/2009/04/have-you-ever-legalized-marijuana.html https://steve-yegge.blogspot.com/2009/04/have-you-ever-legal... It'd have been delightfully ironic had either of these Steves concluded their essays with a named methodology to "just" apply whenever faced with these "let's just" situations but alas...

jabroni_salad 2y ago

I am pretty sure presales as a career exists solely because of the word 'just'. We have to make sure they wont get spooked when we start lifting the rest of the iceberg out of the water.

aprilthird2021 2y ago

Yes, and a very well designed API can be the foundation of and moat for a successful business. Stripe is one of the best examples. Even as hundreds of copycats pop up, their excellent API design and the trust devs have in them to nail the next API design, means they can continue to expand into other financial products with ease.

btilly 2y ago

At a previous employer we had a rule. The only person allowed to say, "just", was the developer responsible for actually making it work. Another developer who said it, just volunteered themselves. It was a rule that worked well for us.

gdsdfe 2y ago
That's a good one!
jrs235 2y ago
Needs to also be for "that's easy"...
sharpy 2y ago
I am totally going to advocate for this at my workplace. I myself am guilty of it - not saying "just", but questioning people's estimates based on my limited understanding of the research they had to do to come up with the estimates in the first place.
- ffsm8 2y ago
  It sounds pretty toxic if you're not allowed to even question other people's estimates. IME that's a large part of Grooming/refinements
  - dambi0 2y ago
    Aiming for an environment where uniformed challenges to estimates are discouraged is an entirely different thing to forbidding any challenges to estimates.
BlarfMcFlarf 2y ago
Punishing people with more work doesn’t make sense in a well run organization. Work is continuous and more work only affects the backlog, not the actual developer’s life or experience.
- 2y ago

karmakaze 2y ago

Yes exactly. The article would be much better positioned as What it actually takes to make systems ideas "just work". Then it isn't about whether it can or can't but rather how it succeeds or fails. Having details about what it takes then stops people from saying "just" because they don't know what they're talking about. But I pretty much agree 100% about DSLs, it's an unnecessary/cute complication. The only people who should be allowed to make them should be ones who have made a successful programming language and updated it to deal with all their mistakes or a 2nd version/2nd language, and still got many things wrong.

deleted 2y ago

[deleted]

fosk 2y ago

Furthermore, API is a product that needs its own lifecycle to be versioned, decommissioned, continuously improved. Often I see developers creating new APIs ad-hoc all the time instead of curating and enhancing the one they already have.