3 ms·

At Google, there are too many complex systems and too many team dependencies to break tasks down into granular chunks, or to shoot from the hip in a pair progra

At Google, there are too many complex systems and too many team dependencies to break tasks down into granular chunks, or to shoot from the hip in a pair programming session. Google runs on design docs. You define the problem, dependencies, risks, end state, etc, in a 20-page doc, and then you drive its development for 1-2 quarters. Google doesn’t do extreme programming, we do extreme ownership. I really prefer it to the time I spent working with Pivotal or Carbon5. They were great, but imo not a sustainable process for mature products. Agile is good for driving a new, greenfield MVP... and that’s about it.

hinkley 7y ago
There’s a lot of power in refactoring, but I’ll allow that some of it is counterintuitive. Anything counterintuitive requires state of mind and experience to line up and that’s quite hit or miss. When that awful Design Patterns book was off the hype train but the new devs had heard about it and asked if they should read it, I would tell them No, read Refactoring twice instead, because it tells you why and when to use this stuff, which is much more valuable. Like feature work, if you know why you are doing something you can often reason out the gaps in the “what” on your own. We sort of take a bunch of XP processes as a given and forget that this was Agile for most people at the time of the manifesto. Scrum pretends it’s separate but is essentially useless without half of XP.
- anonygler 7y ago
  Google does refactoring, but you’re expected to sell the idea, plan its roll out, and measure its impact... and then bring the codebase into a consistent state. I would rather things be consistently “wrong” than inconsistently right. You can assign work to teams to complete, but you must drive the effort and gain buy in. Otherwise it’s not actually worth refactoring.

hinkley 7y ago

There’s a lot of power in refactoring, but I’ll allow that some of it is counterintuitive. Anything counterintuitive requires state of mind and experience to line up and that’s quite hit or miss. When that awful Design Patterns book was off the hype train but the new devs had heard about it and asked if they should read it, I would tell them No, read Refactoring twice instead, because it tells you why and when to use this stuff, which is much more valuable. Like feature work, if you know why you are doing something you can often reason out the gaps in the “what” on your own. We sort of take a bunch of XP processes as a given and forget that this was Agile for most people at the time of the manifesto. Scrum pretends it’s separate but is essentially useless without half of XP.

anonygler 7y ago
Google does refactoring, but you’re expected to sell the idea, plan its roll out, and measure its impact... and then bring the codebase into a consistent state. I would rather things be consistently “wrong” than inconsistently right. You can assign work to teams to complete, but you must drive the effort and gain buy in. Otherwise it’s not actually worth refactoring.