3 ms·

In regard to various software engineering literature and quotes (hofstadter's law, mythical man month, etc) while there's some truth in what they say, what you'

by lojack 10y ago

In regard to various software engineering literature and quotes (hofstadter's law, mythical man month, etc) while there's some truth in what they say, what you'll take away is absolute lies. - Just because you can't reliably estimate a project doesn't give you an excuse to refuse to give an estimate. We get it, your estimate will be off. Whats important is that you communicate deadline changes early and often. - Contrary to everything you hear, software projects can be finished on time. Most of the time we procrastinate at the start of a project and crunch at the end. Stop procrastinating at the start and more projects will be completed on time. Which brings me to... - If you fail to complete a project on time and failed to communicate this impending delay early, this is 100% your fault. This isn't the fault of some stupid law, or book you read. You slacked off and as a result couldn't reliably see how much work was involved in the project and by the time you realized it was probably too late. This is on you.

TeeWEE 10y ago
I totally oppose this. Sometimes there are to many unkowns to give an estimation. Its better to NOT estimate because it doesnt hold any values. 'finished on time'.... This is the waterfall approach. Its broken in its core. So i also disagree with that.
- yitchelle 10y ago
  Sometimes, the time estimate that is put down on paper does not really matter at all. The estimate will force the engineer to think through their planning rather than just doing things adhoc.
- lojack 10y ago
  > Its better to NOT estimate because it doesnt hold any values. This is the core of where I disagree. Giving estimates provide tremendous value to those who depend on your work. It allows them to plan and forecast future needs. You're rarely ever working in some kind of bubble where your work is this mysterious thing that can be done tomorrow or in 4 years. I've never encountered a situation where there's so many unknowns that you can't come up with some number. Requirements change, timelines change, that's all fine. Businesses should be able to adapt to change. Being in the complete dark is much worse. > 'finished on time'.... This is the waterfall approach. I'm not sure what you mean by that? Things can't be late just because you're "agile"?
  - namenotrequired 10y ago
    > I'm not sure what you mean by that? Things can't be late just because you're "agile"? I think TeeWEE means that in modern practice a product isn't "finished", it is launched but continually improved afterwards.
    - lojack 10y ago
      And to that (I know, not your words) I'd say he's incorrectly making the assumption that projects and products are synonyms, when they aren't. Projects are completed all the time, even in Agile.
- EliRivers 10y ago
  The only place I ever worked that delivered on time, within budget, with zero bugs reported from the customer, used waterfall.
- HeyLaughingBoy 10y ago
  Think of the biggest task you've ever completed. Now imagine we go back in time before you started and I asked you: will this take closer to one month or 10 years? Can you estimate that?
afarrell 10y ago
> We get it, your estimate will be off. Many people don't get it. And if you genuinely don't know, then how is claiming you do anything other than writing a cheque against an account of unknown balance? If you feel like you don't have a good handle on how to estimate the project, that is an important sign that: - The scope of the project is actually not well defined. - The tools you are going to be using are ones you don't have a lot of experience with and you have a high probability of running into an odd bug that takes a long time to track down - You haven't broken down the task enough. - The task is large enough that you should actually be biting off a smaller piece of it and estimating that. If you think that there is a significant chance of missing a deadline, you should indeed communicate that as soon as possible. That includes during the meeting where you give your estimate. > Stop procrastinating at the start If you find that you do actually have a bunch of time that you're losing at the start, ask yourself what the causes of that are and seek solutions to those causes. - Consistently get good food every day and good sleep every night - Use https://freedom.to/freedom https://freedom.to/freedom to block HN and reddit. - Make sure that you are clear on the projects' goals and the tools you are going to use. - Make sure you know whom you can go to when you need to get clarification on things. But be aware that there are other causes for deadline slip. > this is 100% your fault If you find yourself in on a software team or a state of mind where your top-of-mind question is "who's fault is this?" get out of there. Pointing fingers prevents organisations from making systems-level changes to avoid them. Furthermore, if you get yourself into the mindset of "I failed and am behind on this project and it is my fault and I need to just buckle down, catch up, and fix it." then you will not do yourself or the project any favors. Take a deep breath (or even a brief walk), find a senior engineer that you trust, and ask for their help in thinking about how the project is structured and how it might be estimated.
- lojack 10y ago
  Keep in mind, these are all things I'd tell myself, not things I'd tell other junior developers. Saying something is my own fault is taking responsibility for things, not pointing fingers. I would never go around blaming junior developers for a project being late and not being told it'd be late. But, when I was a junior developer, I had a tendency to procrastinate at the start of a project and cover up my procrastination by keeping everyone else in the dark. I learned, through time, that over communicating from the outset would help those that relied on my work plan ahead, and it'd also have the effect of helping keep myself on track. A form of personal accountability.

by lojack 10y ago

TeeWEE 10y ago

I totally oppose this. Sometimes there are to many unkowns to give an estimation. Its better to NOT estimate because it doesnt hold any values. 'finished on time'.... This is the waterfall approach. Its broken in its core. So i also disagree with that.

yitchelle 10y ago
Sometimes, the time estimate that is put down on paper does not really matter at all. The estimate will force the engineer to think through their planning rather than just doing things adhoc.
lojack 10y ago
> Its better to NOT estimate because it doesnt hold any values. This is the core of where I disagree. Giving estimates provide tremendous value to those who depend on your work. It allows them to plan and forecast future needs. You're rarely ever working in some kind of bubble where your work is this mysterious thing that can be done tomorrow or in 4 years. I've never encountered a situation where there's so many unknowns that you can't come up with some number. Requirements change, timelines change, that's all fine. Businesses should be able to adapt to change. Being in the complete dark is much worse. > 'finished on time'.... This is the waterfall approach. I'm not sure what you mean by that? Things can't be late just because you're "agile"?
- namenotrequired 10y ago
  > I'm not sure what you mean by that? Things can't be late just because you're "agile"? I think TeeWEE means that in modern practice a product isn't "finished", it is launched but continually improved afterwards.
  - lojack 10y ago
    And to that (I know, not your words) I'd say he's incorrectly making the assumption that projects and products are synonyms, when they aren't. Projects are completed all the time, even in Agile.
EliRivers 10y ago
The only place I ever worked that delivered on time, within budget, with zero bugs reported from the customer, used waterfall.
HeyLaughingBoy 10y ago
Think of the biggest task you've ever completed. Now imagine we go back in time before you started and I asked you: will this take closer to one month or 10 years? Can you estimate that?

afarrell 10y ago

> We get it, your estimate will be off. Many people don't get it. And if you genuinely don't know, then how is claiming you do anything other than writing a cheque against an account of unknown balance? If you feel like you don't have a good handle on how to estimate the project, that is an important sign that: - The scope of the project is actually not well defined. - The tools you are going to be using are ones you don't have a lot of experience with and you have a high probability of running into an odd bug that takes a long time to track down - You haven't broken down the task enough. - The task is large enough that you should actually be biting off a smaller piece of it and estimating that. If you think that there is a significant chance of missing a deadline, you should indeed communicate that as soon as possible. That includes during the meeting where you give your estimate. > Stop procrastinating at the start If you find that you do actually have a bunch of time that you're losing at the start, ask yourself what the causes of that are and seek solutions to those causes. - Consistently get good food every day and good sleep every night - Use https://freedom.to/freedom https://freedom.to/freedom to block HN and reddit. - Make sure that you are clear on the projects' goals and the tools you are going to use. - Make sure you know whom you can go to when you need to get clarification on things. But be aware that there are other causes for deadline slip. > this is 100% your fault If you find yourself in on a software team or a state of mind where your top-of-mind question is "who's fault is this?" get out of there. Pointing fingers prevents organisations from making systems-level changes to avoid them. Furthermore, if you get yourself into the mindset of "I failed and am behind on this project and it is my fault and I need to just buckle down, catch up, and fix it." then you will not do yourself or the project any favors. Take a deep breath (or even a brief walk), find a senior engineer that you trust, and ask for their help in thinking about how the project is structured and how it might be estimated.

lojack 10y ago
Keep in mind, these are all things I'd tell myself, not things I'd tell other junior developers. Saying something is my own fault is taking responsibility for things, not pointing fingers. I would never go around blaming junior developers for a project being late and not being told it'd be late. But, when I was a junior developer, I had a tendency to procrastinate at the start of a project and cover up my procrastination by keeping everyone else in the dark. I learned, through time, that over communicating from the outset would help those that relied on my work plan ahead, and it'd also have the effect of helping keep myself on track. A form of personal accountability.