17 ms·

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be de

• genghisjahn 8mo ago
  Anyone from a sales roll care to speak to this?
  • carefulfungi 8mo ago
    Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.
    • genghisjahn 8mo ago
      Are you in sales or have you ever worked in sales?
      • carefulfungi 8mo ago
        I've been a CTO (with a lot of pre-sales engineering responsibilities) and a VPE responsible for engineering - sales relationships; I've participated in hundreds of prospecting and customer calls and many years of sales planning/strategy/deal review meetings. I can tell you from first hand experience that sales (and marketing, to a large extent) are both strictly measured and held accountable to forecasts. Forecasting a buyer's behavior, or a lead gen pipeline, or deal timing is not easier than forecasting the construction of a new feature.
  • mcfly_c-137 8mo ago
    Really interesting topic. (I’m actually somewhere in between sales and dev - doing Req. Engineering, Concepts and planning). Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes. And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.
• pocketarc 8mo ago
  I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else. Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.
  • devsda 8mo ago
    Unless its the first time they are hearing about it, when a customer asks about a feature, sales should've done their homework and checked with the team doing the work to get a rough estimate instead of pulling a number out of their behinds.
  • ravloony 8mo ago
    Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.
    • SpicyLemonZest 8mo ago
      I understand the intuition, but it's a misunderstanding of how software sales operates. There's no tradeoff between prospects who need new features and prospects who don't, because salespeople love that second category and you'll have no problem hiring as many as you need to handle all of them.
  • loloquwowndueo 8mo ago
• iamflimflam1 8mo ago
  If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy? If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person? The no estimates movement has been incredibly damaging for Software Engineering.
  • geetee 8mo ago
    Most businesses like to pretend change orders don't apply to software.
    • tuna74 8mo ago
      Then you need a new estimate. That is not hard to comprehend.
  • narmiouh 8mo ago
    Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted. I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit. If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work) All software requests are somewhere in between former and latter, most often leaning towards the former scenario.
    • iamflimflam1 8mo ago
      Building a house, adding an extension, replacing a bathroom, building a deck. Many unknowns - you'd still expect an estimate.
  • Rotundo 8mo ago
    If work on a house was specified like a typical software project, no builder would even return your call. "I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".
• xyzzy123 8mo ago
  The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money. Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.
  • pluralmonad 8mo ago
    Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.
    • tuna74 8mo ago
      How much plumbing knowledge do you have?
    • xyzzy123 8mo ago
      Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point. I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable. I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct. Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...
  • mactavish88 8mo ago
• the_af 8mo ago
  I think this is unfair to sales. I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise. When will you recover from your injury so you can play the world cup? When will this product arrive that I need for my child's birthday? When will my car be repaired, that I need for a trip? How soon before our competitors can we deliver this feature? "It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.
  • AnimalMuppet 8mo ago
    But it's the reality of engineering. If reality is unacceptable, that's not reality's problem. But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money. So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly. The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.
    • the_af 8mo ago
      I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world). It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better? And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly). I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets). Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.