4 ms·

You don't have to sell anything. It's part of getting the job done.

mooreds 7y ago
In an ideal world, correct. If this is the case: > changes can take literally 20 times as long as they should while we work out what the existing code does I imagine you have to sell the extra time to (aka convince folks this is the right path) _somebody_. Maybe I've been working at the wrong places :) .
- EliRivers 7y ago
  No reverse-engineering - no new feature or bugfix. That's all there is to it.
  - mooreds 7y ago
    Did the business have to get bit a few times (with, say production outages?) before this became the protocol?
    - EliRivers 7y ago
      "Production outages" aren't something we have to worry about; we don't run a service and once something is working on a customer site, they basically don't tinker around with the configuration or setup. They just use it. But there have certainly been projects that massively overran because the estimates assumed that pieces that already existed were understood and reliable (sometimes they were reliable; they reliably did something, we just thought they were meant to do something else). This happens less now that we assume any existing piece that we don't know about already will turn out to be a minefield.
- crispyambulance 7y ago
  > Maybe I've been working at the wrong places :). I think it's a balance between keeping certain key tasks beyond the radar of PM's (so you have time to think and act) and doing enough "deliverables" to keep them happy. Sadly, PM's in many places have ground-down that buffer to the point where you're maxed out on your backlog and they know everything that's in it. Or worse, they're creating fake deadlines to fabricate "urgency" so that you're no longer in control of the minutes in your day.
  - kkarakk 7y ago
    >they're creating fake deadlines to fabricate "urgency" i've definitely had PMs do this to me when projects were wrapping up and they didn't have any real work to give me. I'd just work at the regular rate and no surprise- no one squawked when i blew past the deadline for the busy work. It's mismanagement imo, with enough experience you start to resent being treated like a precocious child with adhd
- plorkyeran 7y ago
  I think you're fundamentally misunderstanding things. When I've worked on systems like the one EliRivers is describing, you don't have a choice between hacking something together in X time or doing it correctly in 20X time. You have a choice between doing it in 20X time and not doing it at all. If it's a part of the system you haven't touched before, it simply isn't possible to make changes without taking the time to understand what it's currently doing first. The only part of the process that's optional and could theoretically be skipped is turning your notes into documentation consumable by others, but that's a pretty small portion of the time spent.
  - mooreds 7y ago
    Thanks for calling out my misunderstanding. My real question is, how did the business/management learn that they had "a choice between doing it in 20X time and not doing it at all"? How did those lessons get learned?

In an ideal world, correct. If this is the case: > changes can take literally 20 times as long as they should while we work out what the existing code does I imagine you have to sell the extra time to (aka convince folks this is the right path) _somebody_. Maybe I've been working at the wrong places :) .

EliRivers 7y ago
No reverse-engineering - no new feature or bugfix. That's all there is to it.
- mooreds 7y ago
  Did the business have to get bit a few times (with, say production outages?) before this became the protocol?
  - EliRivers 7y ago
    "Production outages" aren't something we have to worry about; we don't run a service and once something is working on a customer site, they basically don't tinker around with the configuration or setup. They just use it. But there have certainly been projects that massively overran because the estimates assumed that pieces that already existed were understood and reliable (sometimes they were reliable; they reliably did something, we just thought they were meant to do something else). This happens less now that we assume any existing piece that we don't know about already will turn out to be a minefield.
crispyambulance 7y ago
> Maybe I've been working at the wrong places :). I think it's a balance between keeping certain key tasks beyond the radar of PM's (so you have time to think and act) and doing enough "deliverables" to keep them happy. Sadly, PM's in many places have ground-down that buffer to the point where you're maxed out on your backlog and they know everything that's in it. Or worse, they're creating fake deadlines to fabricate "urgency" so that you're no longer in control of the minutes in your day.
- kkarakk 7y ago
  >they're creating fake deadlines to fabricate "urgency" i've definitely had PMs do this to me when projects were wrapping up and they didn't have any real work to give me. I'd just work at the regular rate and no surprise- no one squawked when i blew past the deadline for the busy work. It's mismanagement imo, with enough experience you start to resent being treated like a precocious child with adhd
plorkyeran 7y ago
I think you're fundamentally misunderstanding things. When I've worked on systems like the one EliRivers is describing, you don't have a choice between hacking something together in X time or doing it correctly in 20X time. You have a choice between doing it in 20X time and not doing it at all. If it's a part of the system you haven't touched before, it simply isn't possible to make changes without taking the time to understand what it's currently doing first. The only part of the process that's optional and could theoretically be skipped is turning your notes into documentation consumable by others, but that's a pretty small portion of the time spent.
- mooreds 7y ago
  Thanks for calling out my misunderstanding. My real question is, how did the business/management learn that they had "a choice between doing it in 20X time and not doing it at all"? How did those lessons get learned?