3 ms·

Problem: Software projects often discover large new problems late in the cycle. Solution: Do the parts of the project you are worst at first and save the easy

Problem: Software projects often discover large new problems late in the cycle. Solution: Do the parts of the project you are worst at first and save the easy safe tasks for last.

hinkley 6y ago
Solution: stop trying to do the exact opposite of the thing that hurt, because big surprise, that’ll hurt too. I don’t understand why we have such a hard time figuring this out. Too much time sleeping through intro to logic, I suppose. You start with an easy one to prove you’re not completely insane for considering this idea. You move to the hard ones to make sure you’re not going up a blind alley. By the time you’re done, they’ll all be easier (and if they aren’t, then pain is information. Use it.) If you haven’t done the hardest one by the midpoint, odds are good someone is relying on wishful thinking. But doing the hardest one first is masochism. Software is written by humans. Humans need confidence, and practice. Jumping into the deep end will just teach them not to try. People who can do the hardest one first? Aren’t looking for advice, and so you don’t need to write with them as the target audience.
ThePadawan 6y ago
Well phrased like that, that just sounds like Waterfall.
- gonzo41 6y ago
  Don't knock waterfall it delivered the moon landing. Performing teams deliver projects. Methodologies don't.
  - ThePadawan 6y ago
    I didn't!
i_am_new_here 6y ago
Make sure you have the "critical path" in focus and have/create a plan to go along it. "Easy things are easy" and you can do them along the way as side projects. It's tempting to do bike shedding. Manage risks and uncertainties. Though all this requires you to be senior and well experienced and some companies just don't hire these kinds of people, because they are too expensive.

3 ms·

Problem: Software projects often discover large new problems late in the cycle. Solution: Do the parts of the project you are worst at first and save the easy

by username90 6y ago

Problem: Software projects often discover large new problems late in the cycle. Solution: Do the parts of the project you are worst at first and save the easy safe tasks for last.

hinkley 6y ago
Solution: stop trying to do the exact opposite of the thing that hurt, because big surprise, that’ll hurt too. I don’t understand why we have such a hard time figuring this out. Too much time sleeping through intro to logic, I suppose. You start with an easy one to prove you’re not completely insane for considering this idea. You move to the hard ones to make sure you’re not going up a blind alley. By the time you’re done, they’ll all be easier (and if they aren’t, then pain is information. Use it.) If you haven’t done the hardest one by the midpoint, odds are good someone is relying on wishful thinking. But doing the hardest one first is masochism. Software is written by humans. Humans need confidence, and practice. Jumping into the deep end will just teach them not to try. People who can do the hardest one first? Aren’t looking for advice, and so you don’t need to write with them as the target audience.
ThePadawan 6y ago
Well phrased like that, that just sounds like Waterfall.
- gonzo41 6y ago
  Don't knock waterfall it delivered the moon landing. Performing teams deliver projects. Methodologies don't.
  - ThePadawan 6y ago
    I didn't!
i_am_new_here 6y ago
Make sure you have the "critical path" in focus and have/create a plan to go along it. "Easy things are easy" and you can do them along the way as side projects. It's tempting to do bike shedding. Manage risks and uncertainties. Though all this requires you to be senior and well experienced and some companies just don't hire these kinds of people, because they are too expensive.