22 ms·

"Emphasize that the most important part of software development is moving fast." No, that is not the case most times. The most important part of software devel

"Emphasize that the most important part of software development is moving fast." No, that is not the case most times. The most important part of software development is, as with any other part of the company, to maximize the value of the company. That may be speed, but if you have 1m users the most important thing may be to preserve trust, to acquire new customers, to automate existing infrastructure, etc. etc. Speed of software development is not a goal in many environments. Thoughtful execution may be hindered by a cowboy attitude in development. I'm not saying that speed in development is not sometimes the goal (maybe in startups within an enterprise trying to test an idea), but often it's not the most important thing.

deleted 9y ago
[deleted]
inopinatus 9y ago
"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful. To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge effectiveness multiplier for top shelf dev teams. Slow development merely enables lazy programmers (since it conceals their apathy) and gives us waterfall disasters. "Thoughtful execution" is possible in any context, and most thought processes are greatly enhanced by evidential techniques such as rapid prototyping / feature spiking. Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit.
- geofft 9y ago
  I've found maximizing company value to be a pretty good end goal as an individual contributor (and it's definitely the thing I'm most excited about doing when I walk in the door in the morning). It's how you tell whether "fix this bug" or "implement this feature" is higher priority, or whether "do this thing now in our current system" or "experiment with this completely different system" is higher priority. You can do all of those at speed; the question is which to do. And getting it wrong dooms your company, because you're wasting effort. In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.
- quotemstr 9y ago
  > Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit. Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization. It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act. A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!". It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.
  - sillysaurus3 9y ago
    You have to be able to take the very demanding step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!". The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge. I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).
    - quotemstr 9y ago
      Right. You have to create a culture where it's okay to fail. And it's not enough to just say that: you have to actually practice it. You have to let people make mistakes, then do nothing so that other people don't feel afraid to take risks. Hell, reward people for failing. Highlight them as exemplars of people who do things. If you don't fail once in a while, you're not moving fast enough.
- tonyedgecombe 9y ago
  I've seen urgency used as an excuse for sloppy work so often that I can't ever imagine the speed of development being a good metric.
  - inopinatus 9y ago
    I don't conflate the two. Urgency and speed are two very different metrics. Many lumbering waterfall projects have moments of urgency or even panic.

deleted 9y ago

[deleted]

inopinatus 9y ago

"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful. To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge effectiveness multiplier for top shelf dev teams. Slow development merely enables lazy programmers (since it conceals their apathy) and gives us waterfall disasters. "Thoughtful execution" is possible in any context, and most thought processes are greatly enhanced by evidential techniques such as rapid prototyping / feature spiking. Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit.

geofft 9y ago
I've found maximizing company value to be a pretty good end goal as an individual contributor (and it's definitely the thing I'm most excited about doing when I walk in the door in the morning). It's how you tell whether "fix this bug" or "implement this feature" is higher priority, or whether "do this thing now in our current system" or "experiment with this completely different system" is higher priority. You can do all of those at speed; the question is which to do. And getting it wrong dooms your company, because you're wasting effort. In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.
quotemstr 9y ago
> Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit. Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization. It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act. A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!". It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.
- sillysaurus3 9y ago
  You have to be able to take the very demanding step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!". The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge. I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).
  - quotemstr 9y ago
    Right. You have to create a culture where it's okay to fail. And it's not enough to just say that: you have to actually practice it. You have to let people make mistakes, then do nothing so that other people don't feel afraid to take risks. Hell, reward people for failing. Highlight them as exemplars of people who do things. If you don't fail once in a while, you're not moving fast enough.
tonyedgecombe 9y ago
I've seen urgency used as an excuse for sloppy work so often that I can't ever imagine the speed of development being a good metric.
- inopinatus 9y ago
  I don't conflate the two. Urgency and speed are two very different metrics. Many lumbering waterfall projects have moments of urgency or even panic.