Perhaps it’s a bit cynical, but I believe it’s all nonsense. Anyone put in charge of a software project is going to read some books on managing software if he’s not trash. There, he will learn the pitfalls of estimates and etc. and use them in a way that makes sense. Perhaps it’s again cynical, but my assumption is that if people want something within an overly short time-period, they want a piece of shit that meets the minimum interpretation of requirements, which may be possible in their time period.
Ask HN: Developers, how do you estimate projects and write proposals?
81–90 of 109 posts
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#82Estimate * (1.25 n)
where n is the number of non-technical people in the room
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#83(about estimating - I don't tend to write proposals) You could have a look at https://www.estigator.com (NB it's a half-finished side project right now) I'm no longer a contractor, although I have been, and I'm frequently asked by my new employers to provide estimates for dev tasks. Trouble is, businesses/clients tend to see an estimate as a promise, or a target. From the developer's point of view it is hard to do an…
I wrote a similar tool to estigator! It's bare-basic, but aims to solve the same problem: https://uncertain.io/
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#84https://uncertain.io/ I wrote this tool for this exact purpose! A horizontal line means you know nothing. A near vertical line means you are damn certain. Theoretically your stance is somewhere in between.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#85(about estimating - I don't tend to write proposals) You could have a look at https://www.estigator.com (NB it's a half-finished side project right now) I'm no longer a contractor, although I have been, and I'm frequently asked by my new employers to provide estimates for dev tasks. Trouble is, businesses/clients tend to see an estimate as a promise, or a target. From the developer's point of view it is hard to do an…
Thank you for creating this! And please finish this, this will be the most prized tool in my arsenal :)
This is exactly like I do things!
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#86When I first started in programming over 28 years ago, a wise mentor gave me 2 pieces of advice about estimates:
- It takes 4 hours to change a single line of COBOL, once you take compilation, testing, documentation, etc. into account.
- The best way to estimate is to gather as much information as you can, estimate each piece and sum them. Then take that number and multiply it by two. Then take that sum and double it.
Both turned out to be pretty good advice.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#87I want to share some things that I noticed over the years of doing estimations for work related to my small side project.
- Discuss business problem that client is trying to solve. Often you can convince him to change requirements to make it cheaper for him, easier for you and better from technical point of view.
- Know your client's expectations and attention to detail. Some clients want to solve some business problem as cheap as possible. They don't really care about aesthetics and technical nuances of the solution. Others want very specific UI or technical design and won't compromise on any little detail.
- Listen to your gut. Sometimes I feel like something is complicated, but I can't really justify why and end up giving lower estimate. Almost always it was a mistake.
- Always add some buffer for unexpected complications. Bigger the project - bigger the buffer (even in percentage terms).
- I would also recommend to add some buffer for change requests. Almost always client would want to change some small things. It's easier to give bigger estimate upfront than try to charge for every small change later on. Client is never happy with additional charges, even if he knows that he hasn't asked it at the beginning of the project.
- This last one might not be possible in every situation, but I personally always ask for full payment upfront. For really big projects - 50/50. It's not a part of estimation, but this requirement goes along with the estimate. Another option, if the project is big, is to estimate and implement features one by one.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#88In general, I first try to find out what the solution is worth to the customer. This is not feasible in every case but often it's possible to arrive at a rough estimate as to how much additional revenue a solution could potentially generate (preferably) or how much money it would save the customer. It can also mean trying to find out what the customer's most urgent or painful problems are and what the result of alleviating these problems would be.
There are different ways of eliciting this kind of information. Learning to ask the right questions and then listen intently to what the customer has to say is key. There are more methodical approaches such as the Socratic method, which basically is a questioning technique that prompts the person you're talking to consider a matter from different perspectives in order to independently arrive at a conclusion.
Knowing about the benefit of a solution is tremendously useful because it allows you to anchor your price tag to customer value.
While this does not directly provide you with an easy way to estimate the cost of a project it achieves something far more important: Turning software from a cost centre into a profit centre and measuring projects in terms of something the customer actually cares about rather than your time.
As for estimating the actual cost for creating the proposed solution there unfortunately probably is no other way than by experience. However, the risk of giving an overall estimate that's way off can be mitigated by splitting a project into smaller components and deliverables if applicable.
Another approach that's particularly useful for projects of a more exploratory / agile (in the true sense of the word rather than the bromide it's become in many contexts) nature is setting a weekly or monthly budget. Rather than saying "You'll have X by this date." although neither you nor your customer know what X exactly is at that point this frames a project in terms of insights and incremental improvements generated along the way.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#89Earlier quoted context omitted.
Funny, I find measuring opportunity costs much much harder than measuring engineering effort. Even in your example, are those phone calls the substantial costs, or is it customer confidence in your product being lost the main motivation you should do something with the bug? If so, what's the dollar value of this confidence? Also, do you have monitoring good enough in place to see how many customers are hitting the pr…
I think in the first example it's easier to calculate based on the time spent vs the salary + overheads of the employee(s) dealing with the issue. If something took up one hour of my day and I could spend a week one-off to reduce that to 0 hours a day, that's a no brainer.
As always: https://xkcd.com/1205/
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#90Start writing the brief/project charter with all the stakeholders to map out their expectations. Based on it, create the initial plan for the project by breaking it down into smaller tasks, grouped by task lists for better organization. What we do next is to analyze any similar projects we had in the past and how long it took to complete them, so we can estimate time budgets for new tasks. Our clients use https://pay…
Paymo looks amazing, and the price point is crazy low. I can't believe I haven't heard of this before.
You don't use the time-tracking capabilities for software development though, do you? While I could see myself loving to use the tool on my own, being on a team that's required to account for every minute of time (assisted by friendly tracking software no less!) sounds horrible.