[deleted]
"No, it's less effort than that"
181–190 of 388 posts
Re: "No, it's less effort than that"
#182Earlier quoted context omitted.
Well then bussiness people are also disconnected from reality. If a developer can write code and estimate and deliver in time for bussiness, then he is not an employee. He is a founder. What you want is people that deliver like a founder but that don't get any share of the profits. You want gullible people.
Honestly, I think you are an unwilling prime example of a disconnected developer. Why don't you instead try to found common ground and work from there? Who says "business people" aren't capable of dealing with uncertainty? You are making a caricature of a very simple, reasonable request. We're all just people with the same goals. Stop trying to enlarge differences.
>Who says "business people" aren't capable of dealing with uncertainty?
Not defending the parent comment because it's way off base. But come on. You've never seen non-development stakeholders struggle to accept devs communicating uncertainty?
Re: "No, it's less effort than that"
#183Earlier quoted context omitted.
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 sh…
> 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!
Re: "No, it's less effort than that"
#184I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even s…
I feel this pain,
I really do. I want to turn around to fix quickly.
The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.
Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.
My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.
Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.
Re: "No, it's less effort than that"
#185Earlier quoted context omitted.
Using scrum to extract commitments on a sprint is also just waterfall by another name.
Waterfall is not the same as having a plan and commiting to delivering part of it
That's exactly waterfall - make a plan up front, commit to it and focus exclusively on delivery.
Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
Re: "No, it's less effort than that"
#186“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 unkn…
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".
Re: "No, it's less effort than that"
#187“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 unkn…
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.
Re: "No, it's less effort than that"
#188Earlier quoted context omitted.
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 sh…
> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
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.
Re: "No, it's less effort than that"
#189Earlier quoted context omitted.
> Why do you need a baby? > Do you need to grow your own, or could you adopt? > Is it about birth itself? Does it have to be a human baby? > Does the baby need to be related to you? > What if we hire a baby actor? …
Honestly, asking these kinds of business level questions as a dev is a great way to be seen as stubborn and uncooperative in businesses where the mindset of the OP comment has taken root. The managers who complain about their devs not thinking at the business level are usually the ones shooting them down when they do. Why are the coders questioning why we need the baby?
It might be, if it’s directionless pushback instead of genuine curiosity to understand the need of the internal customer.
From my personal experience, people are often positively delighted when you make an effort to try to understand them and their needs.
Not shooting down your experience, but from my perspective it could be seen as a straw man argument in favour of never trying in the first place.
Re: "No, it's less effort than that"
#190Earlier quoted context omitted.
> Is there anything I could be doing better here? Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.
Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly. My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools. If course what this looks like d…
The goal is to leave the company before this becomes your problem. ;)
I say this as the person who gets hired to fix things after they left.