"No, it's less effort than that"

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people?

A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.

There’s a consistent belief here that Programming Isn’t Like Other Work™ and that you can’t estimate it, it’s so mentally taxing that you can’t do it for more than a few minutes at a time in complete silence, and that it’s closer to Da Vinci sculpting the Sistine Chapel than kludging together a few APIs.

It’s fun to think you’re special and easy to do when you’re paid a shitload of money.

There's some truth to what you say.

The problem is that sales can be objectively measured by management. In units.

How does management measure development output?

It can be done, but it take an experienced eng leader to do it.

> I need to call ~10 more people?

I need to write 10 more lines, code for 10 for minutes, etc.

Maybe bonus developers on lines of code written?

Or my personal favorite, bugs fixed!

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines.

You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

It’s not at all like sales quotas. The salesperson’s upside is directly linked to their quota, they are incentivized to fudge it as much as they can.

What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.

Except a sale is a sale; did they buy it or did they not? There's additional nuance for whether they'll buy again or what support they need going forward, but a sale is still a sale.

A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.

I feel the sales analogy is quite general (hit a quarterly/annual quota) but the engineering example is talking about a specific piece of functionality.

If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."

If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.

Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.

great analogy but why doesn’t anyone pay me more for crunching out more tickets?

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.

With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.

Programming is like some kinds of work.

It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.

Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.

Incentive to increase estimate might be:

Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"

Be lazy and only work half the time while delivering "on time".

Only work on the project half the time, spending the other half on something more worthy/interesting.

How is that different from arbitrarily raising quotas?

If your stories are so well defined the dev doesn't have any decisions to make in the process of coding, then they're more of a glorified type writer than a dev.

There's plenty of decisions devs make that impact how quickly they deliver a solution.

Taking a narrow view, maybe. But a sale in a jurisdiction you don’t currently have other customers in could impose significant regulatory burden for relatively little gain. A single 100x sale is very different than 100 1x sales both in overhead you’ll have and in how much leverage the customer will have in the future, etc

This is a bitter exaggeration. Programming is indeed distinctly unlike almost all other work that we have built experience managing as a society. It might be more accurate to say that it combines properties from other existing types of work that are not seen combined in any other type of work.

Again, a very exaggerated/sarcastic version of the quoted sentence. It's impossible to engage if you don't have realistically worded questions.

Go to any thread here on HN about WFH, open offices, 8-hour work days, etc. and tell me I’m wrong.

Yes, this keeps coming up and people respond rather reasonably but people insist on not understanding. In software if something is similar to "cleaning out clogged sewer pipes for the 999,999th time" then it has to be possible to automate it. If I have a task to clean up my code, I'll automate it then it'll take <1 sec to do it. When people say "software is hard" this is not some sociological argument, it literally is a mathematical argument and the reaction should be either acceptance or automating it. If I cannot automate something I need to sit down and think about it the same I think about "Columbus setting out for the New World" or "building the Sistine Chapel" or whatever, i.e. as deeply as my neurological faculties allow me.

For "it's just kluding APIs bro" kind of arguments, I invite you to look at no-code and low-code products and report us how well they work. Is it easy to "kludge together APIs" in this fashion and does it produce viable products? Why? Why not? If it's so easy that it's close to being automated, why can't we have a UI like Photoshop to create API consumer apps?

What cannot be automated has to be exhaustively thought by someone.

One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks.

An example of IT work is installing MS Office on a laptop by hand.

An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.

The difference is that on average devs already underestimate, even when they try not to.

Because you'll figure out how to crunch enough tickets for a minivan!

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

Regarding open offices. The Fed commissioned MIT to do a study on the effect of public observation and found that it significantly reduced people's effectiveness at solving puzzles.

It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations.

The best case is to:

- line up the work in order of priority, taking into account prerequisites

- have sufficient stories in a ready for dev state

- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)

- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog

- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)

- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars

- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)

- be very careful that you don't make this approach the standard way of working

>be very careful that you don't make this approach the standard way of working

Legacy management steeped in manufacturing has entered the chat!

>Only work on the project half the time, spending the other half on something more worthy/interesting.

This is actually a pretty common motivation for devs who work under legacy management.

This is ridiculous. The number of LOC doesn’t define whether something is well implemented. You can’t crank out a better design or proper feature implementation by asking developers to write code faster or write more code in a given day.

You’re restating their point, just with more words.

> The number of LOC doesn’t define whether something is well implemented.

And a phone call doesn't mean a sale closes.

See conversation upthread.

I was going to say something related to car manufacturing as well.

The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.

The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.

If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.

But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster. That’s kind of what Toyota did. Focused on quality, and now they’re making more money than anyone else.

> Hmmm it doesn’t seem unreasonable in that context?

Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.

Just proving my point. Significantly reducing some tech bros ability to do puzzles doesn’t mean that private offices are needed to make the 10,000,000th Rails app.

But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

This would be perfectly true if you replace it for a sales estimate, instead of quota.

The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.

But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Depending on the economic climate and the situation of the company in the marketplace this may be accurate.

If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.

I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.

>Isn’t sales a numbers game for the most part?

At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)

>What’s the incentive for a developer to inflate their estimate?

Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.

And those who, thanks to WFH can handle two jobs at once.

Hell, business types confuse data entry work for dev work.

It's Computer Stuff. It's all the same.

Heh, have we already forgot what happened with Wells Fargo? We need to upsale 10 accounts a day? Random accounts it is!

https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...

I'm tempted to be sarcastic about it, but it's surprising to me that no has mentioned sales quotas being connected to bad behavior. The most important kind is deceptive behavior to customers, and not just the "ordinary, good for the company kind". I mean making promises the company can't keep, or selling future features that require a deathmarch, with the attendant loss of quality/sustainability, even if the C-level doesn't see it.

This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.

If we consider that Fungibility is on a continuum of very low on the left and very high on the right. Where do you think most sales fall on the continuum?

I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.

Not really, the shotgun approach actually works with sales - especially if the sales force has been slacking and not chasing leads.

Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.

This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.

The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.

You forgot elk dinners at nice restaurants! I'll never forget when CA threw everyone parties to celebrate the sale of software the company couldn't use.

P.S. Not really, you covered it nicely under fraud

I've used a credit union for most of my adult life so don't really pay attention to Wells Fargo headlines. Don't know why anyone uses the major banks.

Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work.

As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.

Neat!

Yep, this sounds like the kind of project you make a guess, write up, and it works in that amount of time on your machine.

Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibility.

But 100 phone calls will, there is actually no such relationship in code - in fact deleting code significantly reduces liability, I guarantee reducing sales calls will not have the same effect.

Exactly, I’m glad you’re on my side with this. It’s great to have your support.

That entirely depends on whether or not the team is making something that is going to fulfill an unmet market need.

If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.

Yeah I think of sales people like farmers - there’s a lot they have to get right to get a good crop, but if conditions are poor, nobody gets anything.

Yes, that’s exactly my point.

lol, I'm just thinking of how awful the Manhattan project would have turned out if it had half the invisible things that can go wrong in software deployments.

If software caused mushroom clouds each time it had a problem in the field, nobody would let MBAs run software projects!

That's definitely the sort of thing I'd expect Generic Tech Startup to do, but it certainly isn't standard in every industry. B2B stuff is often a bit bespoke.

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. > Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

Sales quota is a target, estimate is not a target.

> And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?

Good take. We don’t get any % of our marginal profit

That’s not how sales works. At all.

None of that is how sales works. “Just try harder” is bad advice in basically any context.

Everyone in this thread is trying to point out to you that your assumptions about sales are the same as the LoC assumption that equivalently clueless people make about software.

Yes it is.

There is a proven relationship between contacts made and sales made. Which is why sales managers constantly push sales staff to be making calls. Sales has been around for way longer than development, the underlying theory for sales is well known. Just like the underlying theory for manufacturing is well known.

Also it how scam works.

Every time the probability is non null. Small, but not zero.

Law of big numbers always help scammers. And mediocre sales.

No there isn’t. There’s sometimes a correlation, but only people without knowledge of sales think that’s causal. If you want meaningful sales you have to approach it fundamentally differently than you seem to think. Your universal law of sales only applies to commoditized products, and if you’re selling those you’ve already lost.