Why the fuck do we set time based deadlines on projects/goals/sprints?

The only way to know accurately how long it would take is if you've done it before. And if you've done it before why are you coding it again?

And of course when these deadlines aren't met it's rarely the manager that gets shit; it's the devs who failed to meet a guess.

Indeed there should indeed never be any kind of time schedule. Just let everyone who is waiting on something be in confusion about an estimated time span.

More seriously: I understand that as a junior dev you might think that way. More experienced dev are capable of making estimations that are semi accurate. Things can always go wrong so you also plan these things.

Because the contracts that make the money flowing in have a delivery date. I guess you wouldn't be happy either if you were customer and got told "dunno how long it takes. Can be hours, days, weeks or months, who knows". You would buy elsewhere.

OR! How about you get paid by that measure? Yeah you'll get your money. Maybe at the end of the month, or maybe half a year later. You're fine with that, right?

Also, new contracts have to be acquired BEFORE project end so that the devs aren't running empty in between, but someone has to decice when devs will be free for the new things, and that requires planning.

@Codex404 Not a junior developer, but the condescension here is nice. Thanks. 👌

@pk76 wait you are not a junior dev and don't know the value of estimations? Over here that is one of the first things a junior learns before that you cannot be a medior or senior.

@Codex404 Been programming for 14 years.

So no, haven't been "junior" for a while.

Well, it's hard for the rest of a company to generate money off of that programming unless there are some estimates involved. Disregard what you read as judging and read their arguments.

You kinda learn the value of estimates after 14 years

@2stxff Quite the opposite actually. I learned the value of delivering a finished product based on feature and code quality requirements, not time deadlines.

The extreme amount of garbage releases we're seeing in video games right now shows how bad time deadlines are.

@pk76 I too believe in this.

But reality is that it's hard to find funds if you have no idea about the time required to deliver.

These are cold hard facts. I wish it wasn't so, but I've been on all sides of the fences, and you kinda need estimates, expected delivery dates, and sometimes contracts outlining penalty fees if not meeting agreed dates.

@2stxff It's hard to find funds when people won't buy your product because it's "prereleased" garbage either. And it damages your reputation.

From what it sounds like, we're dealing with different business models, different product delivery methods. So that's probably where this difference in perspective comes from.

@pk76 Fair enough on the relations to clients and funding, your world sounds pleasant.

But from a resource planning perspective, in larger shops with several projects, it's vital to know when the required skills are available. I cannot see how the world would work without. When is test ready? When can design start working on project Z? Etc.

"Hi I'd like an appointment at the dentist"

"Sure. I've put you on the list. Goodbye!"

"Wait! What? When is the appointment?"

"Oh! She'll call you when she can take you in. You are currently number 266 in the waiting list. Do you want us to send an SMS everytime you move forward on the list? Standard rates."

"What? That's stupid. I need to know when I have to take the day off. Which date is it?"

"We don't do it like that here. We believe in sending the clients home when the end result is satisfactory, no sooner. The time it takes is hard to estimate, so you'll be contacted when it's your turn. Goodbye!"

*click*

@pk76 I know that sort of ‚programmer‘ 😅 that’s why I would only hire ‚developers‘

@2stxff yeah except certain things are pretty predictable.

I used to cook. Estimating those deadlines is easy. A burger is a burger and med-rare is med-rare. The only timing that has to be factored in is whether the grill has been loaded to where it's cooled down.

Estimating code isn't anywhere near as straight forward. Take my current project: an alternative model text parsing and pattern declaration engine. The design is novel. Despite superficial similarities to some existing stuff, the implementation is drastically different. With something that hasn't been done before, how can you possibly give a time deadline?

@pk76 By breaking it down into smaller tasks and adding some buffer. I agree you that you can't estimate down to single hours, but if you can't even say whether it's days or months, then how would your boss decide whether to spend the money on letting you developing that thing?

And how would he schedule you for the next projects if nobody has an idea when you will be available again?

@Fast-Nop Well I am my boss, so really the customers are my boss. Maybe it's because I offer OTS solutions instead of contract work? But I know damn well they care more about a quality release than whether or not a certain deadline they know nothing about was met.

@pk76 So how do you write your proposals? Uh, sorry, I can't give you any hint how expensive it will be? Just pay me until it's done? Do your customers really give you a blank cheque?

@Fast-Nop OTS is off-the-shelf dude. That's not how that works.

I think its more about self awareness and global vision of your code.

Knowing what a task implies and affects and laying out a clear plan or know that you will be in the approximation and take it into account.

I think being able to estimatr the required work is a must have skill for a dev.

Imagine building a house and you ask the builder when it will be finished and he tells you: “ its done when its done. I don't like deadlines or timeframes because i miss them anyways”.

Well i doubt you would be giving him the trust let alone the coins.

From what I've gathered, it's from a difference in business models. Time deadlines are important for contract work but not OTS work.

And instead of just explaining a perspective I get condescendingly bitch at. Cool.

@pk76 If it's off the shelf, why is your current project having a newly designed parser? Also, off the shelf should be easy to estimate because it isn't new.

@pk76 time based planning does not equal deadlines though.

@Santaclauze I don't have to imagine. I have a great personal experience with this. Two different contractors who've done work on my place.

The one who did give a deadline built my porch, which needed to be reconstructed within five years because he cut corners to meet the deadline he arbitrarily held himself to.

The one who did my bathroom wouldn't give an estimate because they felt it was misleading as they didn't know what they'd be getting themselves into since the didn't do the original construction and weren't sure how well it was done. I've used them for several projects now and everything has been phenomenal.

@pk76 or he could say "I think the bathroom will be done within a week, but if there is a delay I will inform you if there are any delays"
That is what my dad is doing for 35 years now.

AS I said before: estimations are not the same as deadlines.

So that other teams would know when to expect more service cases? So that business partners would be start preparing for new integrations on time, to lose as little money as possible and to live to their promises to their customers? So that business would be able to set their Qx goals and build further expansion strategies?

I could go on.

If a senior specialist cannot make decent estimates, he/she is a poor specialist [I do not care about years. I care about reliability and quality].

After all estimated are not there to tell when you will finish your job. They are there to tell when at the earliest can someone expect the job to be finished. These are different things.

I am sorry for your porch. The worker should have evaluated possibility of failures and how long would it take to overcome them, even if it meant redoing half of the work. And agile approach should have raised red flags before the job was done that smth is wrong - in fact these flags should have been visible asap.

@netikras thank you, this is an actual explanation from a perspective different from my own. I appreciate your insight.

It's okay to miss. You can quanitify misses and smell project risk. The data should be used to solve issues for devs. You have a variance of .2 whenever working at system A?
1. Data can give that feed back, help you better estimate.
2. Mgmt and devs can find necessary to set time aside to root cause, maybe decide to spend time on refactoring or abandoning A or substituting.
That said, I hate estimations these days. It's natural. Spirits up :)

@mathume thanks bud

The real problem here is that the wrong people set the deadlines. It's usually a marketing person, or a manager who when asked, "can your team deliver this by x date?" says yes without really understanding the problem or what it will take to get it done.

Cause you don’t work in / for some nice company in R&D department.

I don’t also ( I think ) but I never got any strict estimates, it’s always let’s try to do it due date and if we fail we estimate it for next 2 weeks sprint.

It’s cause I am in time and material contract instead of fixed price.

So instead of pursuing high wage I mostly spend my time pursuing nice people and interesting things to do that don’t require strict estimates.

Good luck.

@Codex404 no they aren't, I agree with you there. The OP was about _deadlines_ and yet you've been remarkably condescending towards me and twisted it into me not understanding or not appreciating _estimates_.

Then you have the audacity to try to spin this off as me conflating the very thing you did? Fuck right off asshole.

@pk76 note that i never said that it should be on the dead line. But being able to break down your project into visible tasks reflects knowledge and awareness.

Being aware of a lack of knowledge lets say because you didnt build the foundation should be taken within the estimates and estimated as well even if only roughly.

@Santaclauze I am so sorry, I tagged the wrong person. I feel awful. This was not directed towards you. Sorry!

The value of deadlines is in the approximation of the amount of work that can be accomplished in a set time in order to determine allocation of developer time. If the project’s going to be wrapped up sooner rather than later, it’s important to know that in order to secure more work for the people you have. Conversely, if there’s a lot of work left to be done, deadlines are important for estimating how long your team is going to be occupied on a given thing.

However, deadlines created off of poorly written spec or spec that is continually evolving while developers are actively on a given task, adding scope creep, are a waste of time all around. Developers working in such an environment are not “bad experts” for not knowing how to estimate the amount of time a task will take because the person writing the rules doesn’t even know what they want.

Obviously just my thoughts on the matter.

@AmyShackles that's fair. I mostly work with novel things, so there's no spec, hence me seeing no need for it in my limited perspective.

@pk76 ahah all good. It did feel a bit out of context. ;)

@jennytengsonM I am my boss actually. This rant was just about something I see a lot of people deal with that doesn't make much sense to me, although that seems to be due to different perspectives stemming from different business models.

I'd do time breakdowns, but when it's things like "investigate the possibility of vectorization of code point comparisons" or "investigate and implement additional graph rewrite optimizations", it's hard to give a time estimate.

@pk76 If it makes you feel any better, I was once asked to give an estimate on the time it would take to come up with an estimate. *eye twitch*

@AmyShackles *insert idubbz "I want to die" clip*

maybe read : sun tzu - the art of war and you will understand how managers think

You clearly have money and experience so you understand world differently then people who need to start somewhere without both of those advantages.

@vane I came from the second poorest county in my state. Scraping by with a minimum wage job only about two thirds of the year, unemployed the rest of the time. I'm mentally ill, enough so the state considers me disabled. I spent the overwhelming majority of my time without any kind of professional treatment in that regards, because what I have is something most therapists refuse to work with.

Don't tell me about how I have advantages over others. Especially not money when I spent the majority of my life poor as shit.

@pk76 I didn’t want to offend you I just wanted to make the point.

When you start a job or run a business you must agree with some rules to make illusionary money.

I also mentioned sun tzu book cause when you know how software companies work, your advantages and disadvantages you can go to war with those assholes who make stupid rules and make them wrong and as a result make this world a better place to live for others.

From my experience this planet is a hostile place and some people want to take advantage of majorities. That’s how world works, you can improve it by going to war or find a warm place, sit back, criticize and watch as it burns.
Most of us pick the easiest way.

@vane that's the plan. Show how things should be done.

I'm a firm believer that while people do claim they want things by a certain deadline, more than anything they want a working and viable product. I brought it up before, but gaming is currently the prime example where you see this. Absolute garbage is being released as "finished" products to meet arbitrary deadlines, and the community is largely begging them to delay the damn releases. But I've seen this with other things. Hell, a major reason why I no longer program in Ada has to do with a vendor regularly releasing their compiler or IDE by a certain deadline... filled with bugs.

I'll pick up a copy of that book. Thanks for the recommendation.

@pk76 I can assure you people don’t know what the fuck they want even if they tell you that in your face.

That’s the beauty of this world.

What you pointed out is the world shift to more lean and agile approach of making software because of what I mentioned before ( we don’t fucking know what we’re doing on this planet ) and everything that involves people is expensive as fuck.

So world forced software developers to make software with new approach with old tools.

Yes clearly managers got their tools like fancy jira, time, hr, wiki, word, excel, powerpoint whatever tracking apps.
Admins got their infra, cloud, kubernetes, ansible, jenkins, shit like that and all this was created by busy developers so all those assholes can go fuck themselves and live us alone but who took care of developers while they were busy building this pile of shit ?

NO ONE.

They buried themselves for ages, fucked up hard by everybody and themselves.

Here’s your problems explained and if you figure out how to make things easier instead of rewriting IDE third time with same features you will make billions of dollars.

@vane and that's what I love doing and what my work ultimately encompasses. I wound up specializing in text/language. Businesses process tons of it; they inherently need to. If I've got a product that is generally faster and more light weight, that's an easy sell to management (you can process x% more documents per day, or whatever, is a no brainer if the price is good).

But great care has always been taken to ensure that these systems are easy to develop in/with. And that they are released _after_ editor integration has been developed so you aren't fucking around without syntax highlighting or intellisense.

"Yeah but how long until the next release?" I don't fucking know? How about we get the results from usability testing and see what changes need to be made. And after those changes I still can't actually tell you because people don't actually know what they want, so usability testing needs to occur again and maybe they like it even less now and more changes need to occur.

@vane but what I do know is that releasing unfinished buggy garbage hurts reputation a lot more than "ehh, they're more meticulous than I think they should be".

While customers might not be able to tell you very well what they want, they'll sure as fuck tell you what they don't want. And people forget delays a lot quicker than they forget trash.

@pk76 Depends on how many products you have. Let’s say you release 1 good product and 10 trash.
After you release second good one people will forget about those 10 ( numbers may vary )

We tend to remember first and last thing not what happened in the middle.

That’s how corporations operate. They own bunch of companies and some of them release crap but small amount release high quality products.

When there is to much crap they rebrand their logo or something like that and we even don’t know that both games are from same owner.

Ignorance is bliss.

Anyway good luck with whatever you’re doing, have fun.

@pk76 while fuck you too, I misinterpreted the rant. I've not been condescending at all. Anything I said is true. You were talking about time planning and sprints. With sprints there are no real deadlines that is why I assumed estimations. Just because you do not understand Scrum does not mean I'm the asshole here.

@pk76 there is another perspective. Your employer is paying you for your time. And the employer is concerned to have the product generating more funds [i,e. You are an investment, and the sooner it pays off - the better investment it is].
Also an employer could have multiple projects, multiple tasks and planning resources [i.E. Devs' time, i.E. Your time] ahead is naturally essential.