71–80 of 98 posts
Earlier quoted context omitted.
100000%. If I was put through stress to to meet a deadline that I later found out was totally arbitrary "So that I can do more work". I would instantly lose motivation. Everything is made up and the points don't matter. Got it.
Someone should make a modern day boy cried wolf story except it’s with software engineers and fake deadlines.
Earlier quoted context omitted.
This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rational for a company to say, "This is valuable to us if it can be built in three weeks, but if it takes longer, we don't want it." Because three weeks of paying your team costs a certain amount of money, and a cost higher than that puts the value of the work und…
You want milestones and progress over estimates and deadlines. The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. If there is…
There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective.
> "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can.
I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.
> In some cases they even try to compensate by doing it themselves (especially first-time managers). It’s ok to ask people to work a bit harder. It’s your job to find the right balance. It’s an error to work as hard as you ask your subordinates to, in service of an arbitrary deadline you cooked up just to put pressure on them? > I always feel responsible for delivering on time, so I used to work my ass off (weekends…
It is not a fun reality — but in a business where profit is the goal, cadence deadlines are helpful. When used right, they give you a good gauge on how much time the company would like you to spend on the problem. Ideally they calculated that risk higher up for the business’s needs, and you are being assigned the work for a strategy. The frustrating part is this rarely happens in practice :) I’m working at a place no…
“We’re going to spend the next two weeks working on X, so scope your ambitions accordingly—what’s realistic to expect in that timeframe?” seems like a perfectly reasonable and healthy negotiation to have, one compatible with respectful working relationships.
Right, and the way to do this is by dividing work into easily digestible pieces that are easy to reason about, and to _feel_. Agile or lean.
> 5. Being rigid about the deadline
> Sometimes external people will want to change the deadline (especially your PM), or add some scope. Your first instinct might be to respond by saying: “No way, we agreed to X by Y. We are not changing that right now”.
Not sure I like this definition of deadline. Seems more like a random fire up the arse.
---
Deadlines are great for one thing: coordination between departments that don't understand each others' work. If marketing and engineering are trying to make a product together, they need common grounds for getting things done and correcting course. You do this with deadlines. The deadlines might contain work to be done, to reduce risks, or planning could be just "let's see where we're at no later than this date."
Deadlines are made feasible by forcing the team to discuss the work, and ensure understanding within the competent team. Scrum planning poker provides one process (yeah, there, I said it) for that.
I once had a manger asking us line managers how to make the teams feel urgency. I guess it is indeed a question, but it's mostly a question to make fun of, not to be answered. Or at least that's how I reacted when I violently argued against this abuse of my direct reports' stress levels.
Earlier quoted context omitted.
You want milestones and progress over estimates and deadlines. The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. If there is…
> The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. There is no value equation for "the theories and knowledge" that develope…
I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.
There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation.
I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play.
However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.
Earlier quoted context omitted.
Not sure why this got downvoted, management really does not care about your health. They may say things out of social niceties, but they really do not care. Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
>Not sure why this got downvoted Because HN doesn't like comments that are blunt about harsh realities, they like a warm tone that coddles and softens the facts. >They may say things out of social niceties, but they really do not care. My favorite part is when companies pretend to tackle burnouts with giving their workers subscriptions to yoga or mindfulness apps, instead of you know, the sane thing that actually wor…
I’ll go against the grain and say that fake deadlines are incredibly useful. They highlight unexpected costs, they force the team to bring forward hard decisions and push towards action. It’s the same as time boxing or pomodoro. You tell yourself it’ll take an hour. An hour later, you ask yourself what did you actually do and whether it makes sense how you spent your time. I don’t think fake deadlines should be exter…
Earlier quoted context omitted.
This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rational for a company to say, "This is valuable to us if it can be built in three weeks, but if it takes longer, we don't want it." Because three weeks of paying your team costs a certain amount of money, and a cost higher than that puts the value of the work und…
You want milestones and progress over estimates and deadlines. The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. If there is…