10 ms·

I agree with this, but it misses the thing many teams need and that is a process to reliably hit dates they commit to.

• lmm 4y ago
  95% of the time the reason teams "need" that is bullshit internal politics and everyone is better off if you can structure the organisation to not do that.
  • jshen 4y ago
    This is not true for most. Imagine going to a contractor to get a house built and they tell you that they can’t tell you what it will cost or when it will be done.
    • foepys 4y ago
      I don't know about the US but in Germany this is already the case. You get a rough estimate but nothing is set in stone. Overshooting deadlines and increasing costs due to materials not being available or them suddenly costing twice as much is normal. Also coordination between all the various contractors is always getting messed up because the person putting up the scaffolding didn't show up, so the plumber cannot work and cannot come back for 3 weeks, which messes up the plan for the drywall, which gets pushed back, and so on.
      • jshen 4y ago
        But they give you an estimate for cost and time, and are reasonably close to it. I.e. it doesn’t cost 3x the estimate! They could probably do it more accurately but it would lose them bids, so they knowingly low-ball it. You shouldn’t have that problem inside a company doing software.
        • Lio 4y ago
          Of course you have that problem inside s company building software. Engineers low ball partly because they don’t know what’s involved in a new piece of work. Like walking between two points on a map; they don’t know what they’ll run into on the ground. Managers and stake holders then bully the engineers into lowering the estimates because even that’s not quick enough. Worse, they scale the team without discussion without realising that will make the project harder to deliver.
          • jshen 4y ago
            Those are bad managers. I always add a buffer on top of the buffer the engineers add themselves.
            • jacquesm 4y ago
              Bad managers are very common.
    • jahewson 4y ago
      That sounds exactly like a contractor. "It will be done for $x in y months". Actually it was done for $x * 1.25 in y*2 months.
      • biglost 4y ago
        A few months ago i worked at a company which estimated 2 months, after 1 year and a half it’s still not done, i quit a couple of weeks ago But the client, a really bigcopany, it’s angry but stillwaiting, lying to tjeir upper managent to get a few bonuses
      • jshen 4y ago
        1.25 cost is reasonable, and is solvable by adding a buffer. Taking 2x the time is ridiculous, and a professional should be able to do better.
        • dilyevsky 4y ago
          Well if you find such contractors beyond very small jobs please do let me know ;) because I’ve personally never seen one
          • jshen 4y ago
            I’ve built major resorts, and have seen this done successfully many times.
    • tmlb 4y ago
      Makes sense only if you assume building software is like building a house. Imagine getting an author to tell you when the novel they are writing will be finished? Or this: imagine seeking an estimate on when a house will be built, trimmed, painted, furnished, decorated, and filled with every item needed practically and for comfort by the homeowner. It’s a living process that requires continuous reassessment of priorities and scope, and in fact never finishes when you consider the life of the home.
      • jshen 4y ago
        So you think it’s reasonable to have no idea what it will cost, or when it will be done, when building software? You think it’s possible to run a successful business that way?
        • lmm 4y ago
          > So you think it’s reasonable to have no idea what it will cost, or when it will be done, when building software? You think it’s possible to run a successful business that way? It absolutely is; look at some of the biggest and most successful software companies in the world. No-one has any idea what facebook will cost or when it will be done (Zuckerberg has said that he was off by at least 5 orders of magnitude IIRC). No-one has any idea what google will cost or when it will be done. No-one has any idea what amazon will cost or when it will be done. No-one has any idea what netflix will cost or when it will be done.
          • jshen 4y ago
            Google and Facebook are companies. They aren’t features. I know a lot of people at both companies, and they absolutely gave dates and estimation for many things.
        • tmlb 4y ago
          You can have some idea, but it’s not like estimating the time and cost of building a house.
    • cubano 4y ago
      You have obviously never built a house in the U.S., otherwise you would never make such a statement. As almost everyone knows, construction delays and cost overruns are the norm, not the outlyer. Construction projects here very often suffer dearly from the "2 more weeks and/or a couple more thousand dollars" overrun issues. In fact, I'm sure at least several people who have been trapped in a home renovation nightmare LOLed deeply after reading your post.
      • midoridensha 4y ago
        >In fact, I'm sure at least several people who have been trapped in a home renovation nightmare LOLed deeply after reading your post. These stories are SO common (and I've seen it in my own family too) that I truly question the sanity of anyone who takes on a home renovation project.
      • jshen 4y ago
        I’ve worked on the building of major resorts that many people in this thread have probably been to. I’ve seen this done well before, and I’m happy to compare credentials if that’s the route you want to go. Then we can see who LOLs.
        • jacquesm 4y ago
          A major resort is a project that has very large contractors involved and where a part of the upside for the contractor is how well they can manage the buffer they built into the quote for the project. The smaller that buffer the bigger the chance they will win the bid but also the bigger the chance that they will end up losing money on the deal. Houses (not housing tracts) tend to be built by much smaller contractors who are in absolutely no position to absorb any setback without going bankrupt, you can't apply the rules for 'big business' to small time operators and expect the exact same outcome. Constructing resorts also has all kinds of economies of scale that building individual houses does not.
          • jshen 4y ago
            That’s fair, I may have picked a poor example, but I maintain a business needs to be able to have a reasonable estimate of the cost of doing something, and often needs the ability to hit a target date. This is very doable in software, and I’ve seen it done for decades from all levels of the org chart.
    • Foobar8568 4y ago
      Imagine wanting a two floor house with a closed kitchen and once all the wall built you request your contractor to have a single floor one with the garage underground now and an open kitchen with island. With a loose enough contract that they can ask whatever for free. That's the reality of software development.
    • jacquesm 4y ago
      That's pretty much every contractor that I've ever worked with. It's all based on estimates with set minimums, buffers in time and money to deal with the weather and other outside influences and even provisions to deal with the changes in price for raw materials. The only way you are going to get a hard quote is if you buy a prefab or a house that the contractor has already put up multiple times (and even then there will be some room for adjustment). Oh, and foundations are a completely different story.
      • jshen 4y ago
        Yes, I think we are saying the same thing. You use buffers and other means of flexibility to hit a target launch, and it works most of the time but not all the time.
    • musiciangames 4y ago
      I make a point of stopping project managers when they use the analogy of building a house to push back on estimates. What was the contractor doing before the current job? Building a house. What will they do after this job? Build a house. By contrast, software development is doing stuff that hasn't been done before. You may be lucky, and have done something similar. If it's really been done before, you would ideally be using something off the shelf. For me, a project manager who uses this analogy has no place running a software project.
      • mardifoufs 4y ago
        Construction companies can do all sorts of projects, and still usually have to meet a deadline. Do you think every bridge or skyscraper is the same, just because they are all bridges and skyscrapers? And do you think mechanical engineers are also not estimating delivery dates just because they usually create new stuff? Because that's not the case. Also, tons of software dev isn't actually about pushing boundaries or doing something that hasn't been done before. In fact, I'd say most development is about implementing known solutions but in a customized way. Just like every other engineering field.
        • musiciangames 4y ago
          The analogy was house building. Generally a house builder will not be building skyscrapers next month. And the project managers who use the analogy don’t make the comparison with significant and novel civil engineering projects. They make the comparison with having their kitchen extended.
  • yashap 4y ago
    Depends on the company. When I worked for a larger company with a pretty mature product, this was true - deadlines were internal and arbitrary. It also helped that the product was more of a “nice to have” for our customers than “absolutely crucial” - they didn’t truly NEED anything it did (it was software to make social media marketing more efficient). But I’m now at a smaller Enterprise SaaS startup, where the product is absolutely crucial to the customer’s work (core operational software for public transportation agencies). The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers. You need to be able to say “yeah, we can build X by date Y”, and then actually deliver on that.
    • lmm 4y ago
      > The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers. That's just pushing the issue one level higher. Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)
      • yashap 4y ago
        The problem is winning the RFPs. There are some core features and integrations that they really, really want. If we don’t have them, and won’t give a firm commitment to building them, we lose the RFP. “We’ll work collaboratively and evolve the product over time in yet-to-be-determined ways” can work when you have an established relationship and 2-way trust, but there’s not much of that during an RFP. If a competitor commits to their biggest asks, and we don’t, we lose the RFP.
      • 4y ago
• Mtinie 4y ago
  To reliably hit dates, scope of effort must be well understood and it cannot change once a commitment is given. The former is (generally) within the control of the team who is responsible for hitting the date. The latter, (generally) is not. The process is less important than the people.
  • jshen 4y ago
    > To reliably hit dates, scope of effort must be well understood and it cannot change once a commitment is given. this works, but it’s not the only. You can use a mix of buffers and scope flexibility to hit dates too.
• sfuller808 4y ago
  [dead]
• therealdrag0 4y ago
  Why is that? My current team only estimates projects not tickets and does not do scrum, and I don’t notice a difference in performance from scrum teams I’ve been on. Furthermore, I worked on a 18 month project that was estimated by someone who was not on the team that implemented it and it was implemented on time without overtime, and without any special process. Maybe that was unicorn, but it happens. I think just having a manager/tech lead that cares and maintains priorities is all it takes to stay on track.
  • hef19898 4y ago
    Processes are great tools in the hands of good managers / leaders. Good processes in the hands of bad ones, or bad company culture, does not make them good managers. Outside of software, you see the same thing over and over again with Lean Management and TPS.
• jacquesm 4y ago
  > but it misses the thing many teams need and that is a process to reliably hit dates they commit to 40 years of IT experience lead me to believe that this is only possible for the most trivial of projects with nailed down specifications and where the party building it has relevant domain knowledge. In practice such projects don't really exist. Trivial IT projects are rare, specs change, scope creep is a thing and domain knowledge is built up slowly over time. What is necessary is that the work does not occupy more time and effort than it strictly requires. That is still a hard problem, but much less hard than to find a way to hit dates that you commit to, unless you give yourself ample room to deal with the realities of complex IT development work.
  • jshen 4y ago
    I think we’re on the same page, you have to give yourself room to deal with the complexities. It’s not perfect, but it’s a far cry from those saying there shouldn’t be any estimates or date targets with predictable delivery.
• pif 4y ago
  The most usual situation, in my experience, is that a team is required to hit a date that someone else committed to.
  • jshen 4y ago
    Sure, but that doesn’t mean it’s impossible to do decent estimation with predictable delivery in a relatively healthy environment.