14 ms·

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask s

• soft_dev_person 11y ago
  Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...
  • 13hours 11y ago
    I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.
    • soft_dev_person 11y ago
      Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).
  • eterm 11y ago
    Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't very satisfying.
    • 13hours 11y ago
      I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that. Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).
      • eterm 11y ago
        A fixed cost makes it easier to turn and around not pay (in whole or part) if the product is really not up to the standard specified. It's harder to do that if the cost is not fixed but overrunning and the response is "well we just need more time". Also fwiw, the team wasn't selected on price.
        • marcus_holmes 11y ago
          In my experience it's easier and less risky doing it the agile way. You give them a 2-week sprint target. If they fail to hit that, then: a. You don't pay them. b. They're probably going to miss every other target. If you paid the agile shop for everything they did no matter how crap, and withheld payment from the waterfall shop because quality control, then that's got nothing to do with agile vs waterfall, it's got to do with your QC.
        • jsprogrammer 11y ago
          Not pay? Heh. For work performed? OK... That is why my contracts require payment up front.
  • humanrebar 11y ago
    > ...customers that require pretty accurate (cost) estimates prior to even getting the contract. If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.
    • ams6110 11y ago
      That's not exactly true, but it means holding the customer to exactly what they asked for, and having a formal "change request" process for any deviations. The track record of that model of development is not one of successful on-time delivery, but it does seem to make some types of customers more comfortable, even if it shouldn't.
    • true_religion 11y ago
      Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work. If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times. The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long it will take because the developers will be learning while doing.
      • ams6110 11y ago
        And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting). Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
        • Scarblac 11y ago
          And it takes longer, so more billable hours.
    • HillRat 11y ago
  • jameshart 11y ago
    Customers don't need to know the cost, they need to know the price. The most important factor in determining that should be the value of the software to the customer, not the time it will take to produce it.
    • DougWebb 11y ago
      True, but difficult to sell, especially to repeat customers who can calculate the price/hr on previous work.
      • jameshart 11y ago
        Let's say they figure out you only spent 100 hours to deliver them $50,000 of value. It's your job to persuade them that that guy on the internet who says they would sell them 100 hours of dev time for just $5,000 will only give them $5,000 of value (if that). If I have a choice between getting someone who delivers value at a rate of $500/hour versus someone who delivers value at $50/hour, and I need $50,000-worth of software, I should choose the more efficient developer, not the cheapest one.
        • DougWebb 11y ago
          For the kinds of projects my company tends to do, when we're getting into repeat business we're generally not competing with other contractors. Our clients know that the other contractors would have a ramp-up cost that we don't, and an unknown working relationship vs our good working relationship. Instead, they look for per-hour discounts and ways to 'cut costs' while delivering the same value. They also typically have their own development team who don't get paid nearly as much per-hour as my company charges, so they look to share more of the work with their internal team. Since we do product, services, and support, including training, it's hard to argue that the internal team can't or shouldn't do the work. It gets complicated, but in the end we mostly come out alright. Our clients are well aware that taking on additional work reduces our likely development cost but increases overhead costs and raises project/schedule risks. It's a tradeoff they accept, and we work with them to ensure the project is successful. My point is, in the real world you can't just charge by the value you provide rather than by the cost of providing that value. That's a simplistic point of view.
  • kentt 11y ago
    I'd love to know more.
• Ensorceled 11y ago
  It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them: Features will be in: A, B, C Features likely to make it in: D, E Features unlikely to make it in: F, G Nope: H, I, J Hell No: K, L, ..., ZZZ The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.
  • 13hours 11y ago
    Ask them to give you a guaranteed schedule of sales that you will hold them to. They'll say it's absurd, you can't predict that. Turns out it's the same with software dev. If you find yourself arguing about this with management or sales, they're not trusting you to be the expert at what you do. Tell them that.
    • shimon 11y ago
      Actually it's remarkably similar. Sales has a pipeline of deals, and someone has an estimate of how much will be booked over the next quarter. This estimate is a key part of managing the sales team and is directly tied to their compensation. Can you imagine if developers explicitly had a code quota to work to? We usually don't, for very good reasons, but salespeople certainly are held to delivery standards on work that isn't fully predictable, so you can kinda see how they might expect the same from software teams. And the analogy continues to work. There is a pipeline of feature requests, some at the vague-idea stage and some nearly shipped. You can provide more accurate ship-date estimates for the nearly shipped ones. And a person with good judgment who knows the stakeholders can provide a better estimate than someone uninformed or unthoughtful whether we're talking about sales or software builds. Further: sales has a bookings target, but also has the freedom to meet that target with various deals. Similarly, product teams will have launch targets, but need some freedom on what exact features are included because per-feature costs aren't predictable.
    • paulddraper 11y ago
      Have you ever done sales? Sales quotas are extremely common.
• eterm 11y ago
  But there's a difference between "production ready" and "customer ready" which Agile practitioners sometimes seem to forget. In many businesses, software is not the core business, you're not building software for yourself, you're building it for other stakeholders. It's not acceptable to say "Well it only does 20% of what you wanted". What happens when things start to slip, so in fact you won't have something the business thinks it can present at christmas? "Don't worry, we'll just keep working on it until it's ready" after having spent 6 months on it isn't good enough. It's not a bad thing to do a lot of estimating up front so the business can make an informed decision about whether it really wants to commit to the effort, rather than finding out during all the sprints about the growing effort required to get it to where the customer or internal stakeholder is happy.
  • humanrebar 11y ago
    > It's not a bad thing to do a lot of estimating up front so the business can make an informed decision about whether it really wants to commit to the effort... You're assuming the estimate is worth much. Which is what much of the industry is doubtful about. To underscore the point, most estimates are single values (eight months), not confidence intervals. A better answer would be, "There is a 50% chance that we get it done between six and seven months from now, assuming requirements don't change." ...but even that assumes that all along the way, the project stakeholders are keeping in mind how many (how do you quantify?) requirements were added and discovered.
    • a3n 11y ago
      How it's said: "There is a 50% chance that we get it done between six and seven months from now." How it's heard: "Wa wa wah, wa wa, we get it done between six and seven months from now."
      • DougWebb 11y ago
        You forgot the "assuming requirements don't change" part. What's actually heard would be "Wa wa wah (up to) six months from now (guaranteed) wa wa."
• Kurtz79 11y ago
  "So why waste valuable time to do all this, if you know it's not the truth anyway ? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that." This maybe is applicable for a company developing new products internally, but for projects delivered to third parties, delivery dates are part of contractual obligations. Estimates are hard, but it's not like predicting the future with a crystal ball. Good developers in general get better as they gain experience in the domain, and in estimating itself. Good project managers in general get better at spotting murky requirements that might be causing problems down the line, and try to clarify them early with the customer. It's not a perfect science either, but it's a necessity in many real-world scenarios.
  • jsprogrammer 11y ago
    Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver? Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.
    • diego_moita 11y ago
      The secret of a consultant's work is not to craft software, it is to craft contracts. Evidence : CGI never got burned by their fiasco on delivering Healthcare.gov
    • Ntrails 11y ago
      >Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver? Because you know full well that the contractual time limits will not, in fact, ever be relevant as you've added some neat tricks so as soon as the spec changes you get to adjust them (and the spec always changes). One assumes therefore that the commitments are simply part of the bidding process as you try to craft a somewhat realistic but very attractive looking bid
    • paulddraper 11y ago
• mannykannot 11y ago
  I am not so sure there is a fundamental difference between what the article proposes and what you describe. You start by saying this will not work, then in your description of what you do, there are many places where you estimate - or should I say guess? - what is feasible, and when. The methods described in the article are analysis and extrapolation from experience, with an emphasis on identifying those areas that are most problematic due to some combination of uncertainty, importance and dependency, and giving them priority. You don't seem to be doing anything very different. Nowhere does the article say you have to schedule weeks or months on this.
• gadders 11y ago
  "Hi. I need you to build me a house. It needs to have three bedrooms, two garages etc. How long will it take?" "Well, we can definitely get you something by Christmas. It might be a bedroom, we may have just done the garages. Who knows? Can you write the cheque now please?"