5 ms·

Can’t tell if April Fools joke or not because I know places like this and it’s a nightmare way to build software.

by rokob 3y ago

CaptainOfCoit 3y ago
Want to expand on exactly why it is a nightmare? Core idea seems to be about focus: decide one thing, "work like hell" to do that thing, then move on to the next thing.
- eddieroger 3y ago
  In my experience, this part: > pick an aggressive date to ship the first headline From the way I've seen this done, the headline is too big (despite the article calling out a realistic example) and the timeline is too aggressive (not addressed at all). Maybe it's fine for a startup or small org where things can be ignored, but I've got lights to keep on and users to support, and "work like hell on this and only this" doesn't really fly, or if it's the actual expectation, is awful.
- ghaff 3y ago
  Any reasonable idea can be taken to an extreme but some variant of "keep your focus on your key goals" doesn't seem unreasonable to me.
- drngdds 3y ago
  Working like hell to meet an arbitrary deadline at all costs is a nightmare
baxtr 3y ago
How come it’s a nightmare at these places?
- johnobrien1010 3y ago
  This is a joke, and the reason why is because even if you “deliver” a headline, you are unlikely to be “done”. It runs counter to the approach of incrementally shipping functionality, listening to feedback, and adjusting. Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. This is a nightmare, because you end up working long hours on valueless work… and upset all your stakeholders by ignoring their urgent requests to deliver small fixes and enhancements to instead just do the one thing you said you would, even though it ends up being worthless.
  - ergonaught 3y ago
    If you cannot simply articulate the actual need met by whatever you've shipped, you have failed to understand that need and probably even what you shipped.
  - aerhardt 3y ago
    The face of the author, if this isn’t a joke and commenters in the thread are categorically affirming it is. Honestly, I don’t see why a variation of this wouldn’t work. It’s like a headline is a sprint goal or an epic or whatever agile artifact you choose… You can still apply good engineering practices from there on: splitting the work into smaller bills, working against a solid definition-of-done, testing rigorously, etc.
  - baxtr 3y ago
    How can this be a joke if there are companies that actually work like this?
  - lelanthran 3y ago
    > Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff. After all, look at the example headlines: “You can now rent VMs through an API”, “we rolled out FSD autopilot”, “Treasury is available in India”. Those are all goals! "Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business. No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high. [1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
    - johnobrien1010 3y ago
      Responses inline. > Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff. [JO: I don't understand what you mean here. Are you saying the goals should all be appended with "and the customer buys it?" So, "You can now rent VMS through and API, and customers do?" In which case, wouldn't that be something that has to happen over time and cannot be delivered solely by engineering by an arbitrary date?] After all, look at the example headlines: “You can now rent VMs through an API”, “we rolled out FSD autopilot”, “Treasury is available in India”. Those are all goals! [JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success. If you goal is "customer can now rent VMs through an API", my assumption is that to meet that initial goal a MVP will be delivered. My further assumption is that the MVP will not have all the features it will ultimately need to be commercially successful and so will need to be iterated on to be better than the alternatives customers have available to them. So, devoting engineering resources to the next headline and not iterating and improving the MVP would be a mistake. If you keep doing that, you end up with a bunch of half-baked marginal products, none of which is successful.] "Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. [JO: I disagree. In the B2B setting at least, I've seen customers cancel because commitments to make minor enhancements for them were not honored. It is rare but it does happen. In addition, while customers rarely cite a specific bug as the reason to cancel, they often cite things like "bad UI" or "bad usability" or "lack of adoption", which IMHO is sometimes the way that customers articulate their experience and/or the results of working with a buggy product.] I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business. [JO: Can you tell me more about what you are thinking about here? In general, I think Microsoft is a tricky example to use, because they have something of a "natural monopoly", and unless you happen to be working at another company that also has such a natural monopoly, an example based off Microsoft may not be applicable.] No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high. [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.] [1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher". [JO: On that we agree; one of my engineering colleagues used to say, if you say everything is urgent, you are letting the other person decide the priority. A good PM should run interference between such customer requests to provide useful and realistic prioritization, otherwise there is no-prioritization at all.]
onionisafruit 3y ago
I’m not sure either. The subject matter and article date scream April Fools, but the article doesn’t yuck it up with increasingly ridiculous examples.
deleted 3y ago
[deleted]

Can’t tell if April Fools joke or not because I know places like this and it’s a nightmare way to build software.

by rokob 3y ago

Can’t tell if April Fools joke or not because I know places like this and it’s a nightmare way to build software.

Want to expand on exactly why it is a nightmare? Core idea seems to be about focus: decide one thing, "work like hell" to do that thing, then move on to the next thing.

eddieroger 3y ago
In my experience, this part: > pick an aggressive date to ship the first headline From the way I've seen this done, the headline is too big (despite the article calling out a realistic example) and the timeline is too aggressive (not addressed at all). Maybe it's fine for a startup or small org where things can be ignored, but I've got lights to keep on and users to support, and "work like hell on this and only this" doesn't really fly, or if it's the actual expectation, is awful.
ghaff 3y ago
Any reasonable idea can be taken to an extreme but some variant of "keep your focus on your key goals" doesn't seem unreasonable to me.
drngdds 3y ago
Working like hell to meet an arbitrary deadline at all costs is a nightmare

baxtr 3y ago

How come it’s a nightmare at these places?

johnobrien1010 3y ago
This is a joke, and the reason why is because even if you “deliver” a headline, you are unlikely to be “done”. It runs counter to the approach of incrementally shipping functionality, listening to feedback, and adjusting. Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. This is a nightmare, because you end up working long hours on valueless work… and upset all your stakeholders by ignoring their urgent requests to deliver small fixes and enhancements to instead just do the one thing you said you would, even though it ends up being worthless.
- ergonaught 3y ago
  If you cannot simply articulate the actual need met by whatever you've shipped, you have failed to understand that need and probably even what you shipped.
- aerhardt 3y ago
  The face of the author, if this isn’t a joke and commenters in the thread are categorically affirming it is. Honestly, I don’t see why a variation of this wouldn’t work. It’s like a headline is a sprint goal or an epic or whatever agile artifact you choose… You can still apply good engineering practices from there on: splitting the work into smaller bills, working against a solid definition-of-done, testing rigorously, etc.
- baxtr 3y ago
  How can this be a joke if there are companies that actually work like this?
- lelanthran 3y ago
  > Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff. After all, look at the example headlines: “You can now rent VMs through an API”, “we rolled out FSD autopilot”, “Treasury is available in India”. Those are all goals! "Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business. No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high. [1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
  - johnobrien1010 3y ago
    Responses inline. > Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff. [JO: I don't understand what you mean here. Are you saying the goals should all be appended with "and the customer buys it?" So, "You can now rent VMS through and API, and customers do?" In which case, wouldn't that be something that has to happen over time and cannot be delivered solely by engineering by an arbitrary date?] After all, look at the example headlines: “You can now rent VMs through an API”, “we rolled out FSD autopilot”, “Treasury is available in India”. Those are all goals! [JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success. If you goal is "customer can now rent VMs through an API", my assumption is that to meet that initial goal a MVP will be delivered. My further assumption is that the MVP will not have all the features it will ultimately need to be commercially successful and so will need to be iterated on to be better than the alternatives customers have available to them. So, devoting engineering resources to the next headline and not iterating and improving the MVP would be a mistake. If you keep doing that, you end up with a bunch of half-baked marginal products, none of which is successful.] "Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. [JO: I disagree. In the B2B setting at least, I've seen customers cancel because commitments to make minor enhancements for them were not honored. It is rare but it does happen. In addition, while customers rarely cite a specific bug as the reason to cancel, they often cite things like "bad UI" or "bad usability" or "lack of adoption", which IMHO is sometimes the way that customers articulate their experience and/or the results of working with a buggy product.] I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business. [JO: Can you tell me more about what you are thinking about here? In general, I think Microsoft is a tricky example to use, because they have something of a "natural monopoly", and unless you happen to be working at another company that also has such a natural monopoly, an example based off Microsoft may not be applicable.] No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high. [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.] [1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher". [JO: On that we agree; one of my engineering colleagues used to say, if you say everything is urgent, you are letting the other person decide the priority. A good PM should run interference between such customer requests to provide useful and realistic prioritization, otherwise there is no-prioritization at all.]

onionisafruit 3y ago

I’m not sure either. The subject matter and article date scream April Fools, but the article doesn’t yuck it up with increasingly ridiculous examples.

deleted 3y ago

[deleted]