201–210 of 324 posts
The mythical man month ( required reading for most CS programs ) goes into a historical and production aspect of why software projects take longer than what you think and what you expected. Also, there is a law named after author called the Brooks's law : "adding human resources to a late software project makes it later" https://en.wikipedia.org/wiki/Brooks's_law In most industries, if you are running behind schedule…
I always think of project tasks as flow charts, where every item either takes 1 day, or 1 week. There's no way of really knowing in advance. Complications happen. It makes it really hard to calculate the "expected value" of 5-10 tasks.
Earlier quoted context omitted.
Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.
Wouldn't it be 240%?
Earlier quoted context omitted.
> But when you advocate clearly for your needs as a professional, people are generally reasonable. This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.
As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.
2. This is why "agile" tries to avoid estimating more than a few weeks. The more tasks you have in there, the more you estimate is likely to be really off.
Earlier quoted context omitted.
Isn't it the same in price negotiation? Only the producer knows the costs. Perhaps the difference is that money can be shifted around more flexibly. Even if I come out with a negative money balance from a negotiation (costs more than the buyer pays), it might be worth it for long term goals. But you cannot borrow time. You cannot do the 1 week project in -1 weeks and then compensate by doing the next 1 week project i…
A sales negotiation is pretty zero sum. There is little advantage in paying more for the same product. However, Giving a developer more time will often improve the quality of the output.
Some deals are inherently negative sum - if you bought a lemon.
Usually it just comes down to fuzzy/missing/changing requirements. A lot of times people know that they want something, but they don't know exactly what. Or they're absolutely sure they need feature x, but then later they realize they don't, but they missed out on developing other more fundamental features.
An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…
> You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. This. I have PMs who will ask me over and over until I give a number and I've learned to stand my ground. Because if I don't, I end up being responsible for the estimate I've given (as I should). Now I make it clear that I will not give a number…
You're not responsible for an estimate you give, the person who's asking for it is.
This is the key difference between an estimate and a commitment: If you give someone an estimate, they are responsible for steering the project using that information. If you give someone a commitment, you are responsible for meeting that commitment.
This is why very few people actually want estimates. They want commitments, but they will ask for estimates to get an answer and then interpret them as commitments. Most people asked for estimates know this intuitively, thus "doubling and adding 10" and other communication strategies to turn estimates into safe commitments before they are communicated.