Stop With Software Estimates

[@davidr2421]

I see a headline that confirms my personal bias, I click

[@lifelover69]

my man

[@vaolin1703]

based

[@thebabyprogrammer]

I see a funny comment that I totally agree, I press like. Me a simple man

[@realkyunu]

W. Also: Ignore everything that might contradict your personal bias and you will be truly based.

[@1130MarsV]

Bias? Cold hard fact at this point

[@ryanpmcguire]

It's like being dropped in a maze and asked "how long will it take you to escape?"

[@roan1366]

Haha, love this analogy

[@khennessy785]

This an amazing analogy holy shit

[@asimplenameichose151]

The similar analogy we used at the previous company I worked for was, "I just dropped a penny on this football field. How long will it take you to find it?"

[@thatryanp]

I've had some stakeholders I would have absolutely loved taking through one of these exercises. When they give their estimate, argue their number down, then when they go overtime, start demanding progress updates every 5 min

[@moe4b]

As the maze is being built around you

[@codeline9387]

What one programmer can do in one month, two programmers can do in two months. (c) Fred Brooks

[@bradclements1815]

I think you left out some other things Brooks said. Something like, as the number of developers increases, the growing communication overhead reduces project performance. So 2x programmers might take 2.1 months, not 2 months.

[@ninetydirectory3798]

@@bradclements1815 Can't that be optimized?

[@Capiosus]

@@bradclements1815 PoV: you're not good at math

[@automatescellulaires8543]

how many engineers does it take to change a light bulb in less than a millisecond ?

[@delta3244]

It may not be possible to give good estimates in general, but for smaller projects - ones that "feel like" they'll take less than a month, "twice as long as I think they will" has proven startlingly accurate.

[@timop6340]

I remember some speech about estimates that suggested simply creating new tasks all the time with the same logic (huge things split to multiple tasks mostly) and task amounts become the most accurate estimates.

[@rickybobby7276]

Until someone asks for a breakdown and everything appears slow and you can’t justify why.

[@markharding44]

I have always estimated using this. Estimate it then double it and like you it’s always been reliable.

[@Titere05]

Yeah, twice as long as my pessimistic estimate is usually spot on

[@AndrasBuzas1908]

Always add 15% more time than you think

[@marktarbogast]

You know it's not going to take 10 million years. You know it's not going to take 30 milliseconds. You can always provide an estimate. The trouble isn't with estimating. It's with how estimates are used. Estimating is a legitimate skill. Understanding what estimates mean is also a legitimate skill. The vast majority of managers don't know what estimates mean. When estimates just function as commitments, the result is long hours and demoralization.

[@wowkster]

Couldn’t have said it better myself

[@user-sl6gn1ss8p]

According to my quick mafs, the geometric mean between 30ms and 10 My is roughly a month. So I expect it done by october.

[@Patman128]

Yes, estimates are supposed to mean "it's probably like 50-80% likely it will be done at this time", and then get taken as "it will 100% be done at this time". Then those estimates get combined into "the entire project will 100% be done at this later time". Managers who actually understand statistics are rare.

[@boines69]

Yeah but at the end of the day that's not how people will handle this

[@davidr2421]

@@marktarbogast Psh yeah maybe it won't take *you* 30 milliseconds.

[@SamBalducci]

I started my first software engineering job in 1991. I am in 2024 and for my whole career I can count on one hand projects that landed with 10 to 15% of the original date. Most of my projects were many months to a year late because most of the time the people wanting the product or writing the requirements did not know what they wanted. The book the Mythical Man Month said this in 1975, and it is still true. You can guess but you will never be correct. There are so many things that can go wrong. The project sponsor may not know what they want, budgets can get cut, your lead developer leaves, people get sick, scope creep, under scoped need or the customer leaves or does not want it anymore. Your estimates are just never going to be accurate.

[@asimplenameichose151]

This just happened to me on a current project I was heading up (technically). Very small initial project. Nearly everything you mentioned except customer abandoning / lead dev departing (both of which happened on my previous big project at different times; I became the lead on it and put in months of 80+-hour weeks to deliver what remained, we over-delivered on-time or ahead despite massive obstacles, then the client completely flaked out ...). Important team member sick for a month. Repeated requirements misunderstandings. Client communicates precise opposite of the requirements they actually want, and when asked later (post-implementation), provides totally different answers to basically the same questions. YUGE scope creep (management says the mobile app is also going to be part of this cycle, when for months the mobile app was _absolutely not_ anywhere near this cycle). On and on. Honestly just considering the frequency of this kind of thing in my own career (~15 years) is making me hesitant to even go into work this week. It does often feel like living with or around delusions continually while doing insane mental gymnastics around bamboo skyscrapers.

[@TheSuperappelflap]

I remember on my first job out of college, around 2019, I was hired by a small company to work on a computer vision project they had been fiddling with. They were using a U-net which was a 2016 architecture. Within the first 2 weeks I concluded that this architecture wasnt going to achieve the accuracy they wanted. So I told the boss man that we'd need to start over from scratch with a current year architecture and that the project would take about 6 months. He told me to shut it and do my job. So I worked on it for another 9 months or so, before he relented and let me start over. Project was done 6 months later with the desired accuracy. And then he didnt renew my contract, I guess he didnt like that I was right.

[@artemsokolov5007]

" You can guess but you will never be correct." it depends on how you define of being correct. For example - estimations shouldn't be just 1 nubmer or 1 date. as you said "many thing can go wrong" - you should just reflect this in you estimation. It simply should be just a probobalistic distribution. Then "bein correct" is just a matter of statistical retro analysis and how far your estiamted distribution from real data.

[@SamBalducci]

@@artemsokolov5007 Do you work with a management that believes that? I mean really believes that? I have worked across five different industries and twelve different companies, and you give them a date even if you padded the date and that is the date. There is no "estimate". There is no we are a week or two off they want the date, and they want the date to be exact because that date will be published to customers or other groups and that is all that matters. Most management do not see or hear "estimate" they see whatever you give them as the final date regardless of what is happening around your company. Our company recently went through layoff, and we lost three people on the team, the date we spoke about three months ago was what they were still expecting. You can talk about estimates, but everyone must agree with what an "estimate" happens to be because unbelievably many people do not understand that an estimate is a guess not an exact date.

[@litjellyfish]

Well that its why its acalled an estimare. they are no suppose to be correct as they are... estimates..The more info and past experience the more your have an estimate and less a guess: I always say we should estimate more. Big reason is that it forces one to think. I love planning poker and I also love role play the whole project. Don't know why not more does it. When I worked at a game company I tried to push for it. The teams loved it, but the scrum masters and agile coaches was so reluctant. Maybe they did not like the idea that a Producer / Product Owner "invented" better tools than those provided / brainwashed by the whole church of Agile Scrum?

[@dandonofrio8441]

I remember getting reprimanded for not being able to give accurate estimates… as an intern.

[@TricoliciSerghei]

Same brother same..

[@XDarkGreyX]

Yeah, my bosses don't get it either and as a trainee i learned that you just gotta give them a number but shouldn't go overboard. "Realistic" estimates is not sometjing they are willing to accept.

[@TricoliciSerghei]

@@XDarkGreyX Oh, they will, the easy way or the hard way.. You can sugarcoat it as much as you or someone else wants.. If something takes 2 months to deliver, and they don't want to hear it, usually it still takes 2 months to deliver, and in the end they're like, well, at least it's delivered and working. Don't put too much stress on yourselves people.. Administration knows much less than you about the code or the project.. And it always feels easier to do something, when you're not the one doing/implementing it.

[@potato9832]

People love to wax poetic about learning from being wrong, but in practice being wrong is how you lose your job. The industry does NOT reward developers who were wrong.

[@MrLordLowbob]

yeah. I'm lucky that my first mentor already told me: just make a decent guess what you think, double it because it always takes longer and then double it again, because either other stuff will interfere or people change their minds in the mids of it. that has 2 effects, either I really need such quadrupled time and only rarely fail some estimates (at least if the workload isn't way too big to even be decently estimated) or I have time to refactor stuff and clean up code that I otherwise wouldn't get time for by management. as long as its not critical to the business (e.g. bugs in production) I won't really say when I'm done early either.

[@believablybad]

I’m starting to think Flip is a figment of Prime’s imagination

[@AlesNajmann]

"Plans are useless, but planning is indispensable." --Dwight D. Eisenhower That said, we have to start somewhere and have at least an idea what we are going to build.

[@heidebaer41]

Mgmt: gibs estimate Engineer: heres estimate with assumptions Mgmt: proceeds to nuke all the assumptions Also mgmt: y project overrun?

[@ajward137]

Exactly so. Product managers in companies with software products usually hold budgets that are fixed each year. Estimates are fine, but they come with caveats: constraints, assumptions, risks. If you can get the product manager to understand that, you're 90% or the way there. I was PM for a major maritime product, and budgets were set each calendar year, then the product manager worked out what they wanted to do with the budget. Estimates are generated and reviewed, risks, assumptions and constraints are published; I produced a plan; things happened, projected budget (but not timescale) overruns about 10%, and we had a problem: I can't let developers book to a budget that is spent. So I ask - what do I tell them to book to? YOu don't give me a contingency budget, so surely the Product Manager has one. Apparently not. He says: I don't know, but you can't let them book to this number. It's a requirement that all empoyees complete an accurate timesheet, indicating how many hours to each booking number. Essentially, there is no contingency at any level in the company for this occurence. Turns out this system is new, and nobody asked a project manager if it would work! They found a slush fund to round out the year: only an accountant or C-suite exec. could have designed a system so hare-brained stupid!

[@lifelover69]

accurate

[@justpatrick_]

Easy, just double the estimate, rip the bandaid early

[@pencilcheck]

Engineer: angry setting up meeting to explain, mgmt: no can do, deal with it

[@matthijszeeman5351]

You missed: mgmt: that estimate is too high, lower it

[@skinneymoney]

The correct estimation for every development activity is: However long it takes.

[@YateyTileEditor]

A long time ago I got a verbal warning in writing for saying almost exactly that

[@parkerwarner8688]

These comments are so refreshing to me

[@pieterrossouw8596]

@@YateyTileEditor a verbal warning in writing? oh shiiiit.

[@markbond08]

“Software engineers explaining why they shouldn’t have to hit deadlines” is one of my favorite genres of article

[@TheSuperappelflap]

We really shouldnt have to, though.

[@tHebUm18]

Worked in software for coming up on 8 years now across two companies. I've never had a deadline. Seems like a failure of management to have it any other way. Deliver most of what stakeholders are asking for in reasonable timeframes, they tend to be happy and trust you to continue in the future.

[@dorktime4526]

Deadlines are a problem that goes all the way to the top. The CEO gets a sort of "deadline" to make the line go up by x%, and will do anything, even destroy the company, to achieve some perceived deadline for that growth. It's always people that don't understand something that demand unreasonable goals, and then that carries all the way down to the employees.😢

[@TheSuperappelflap]

@@dorktime4526 and that's why publicly traded companies are terrible to work for as an IT guy.

[@GregMcNamer]

Haha, agree. Yes, software is complicated. And having someone else assign an arbitrary deadline for an arbitrary effort is unacceptable. But developers need to be able to ballpark the amount of time and effort something will take, and if you don't do it as a developer, someone above you is going to do it for you and hold you to something you didn't agree to.

[@Whateverworksism]

Small note, he's actually CTO, the CEO is Jason Fried.

[@limbo3545]

Prime: Flip! Take this out! Flip: Guess I leave that in lol!

[@HelpRat1729]

Love the zoom at 1:08 - FLIP deserves a pay raise just for this xD

[@Cyanide300]

Building software that is even marginally novel is an _invention_ process, not a construction process. And it would probably be easier to get business types to understand why estimates for medium to large projects are completely useless if we said things like "You want us to _invent_ a new web app?" rather than "you want us to _build_ a new web app". Because building large novel apps has more in common with inventing the light bulb than it does with building a skyscraper.

[@Th3T1redPanda]

and if you find useful code on the net which could help you, it is a mess so big that cleaning it would take require a project for itself

[@HVDynamo]

I’ve never thought about it this way, buy you are 100% right. I’m iterating the software build as I go and see things that wouldn’t quite work like I initially expected. That iteration is so much more in line with inventing something vs building. Building something would imply there are already blocks you just have to arrange in a certain way, but most of the time we are building or at least adapting the blocks because the even when they where intended to be re-used they inevitably miss one key feature the new project needs. In my experience too I think too many companies try to build re-usable assets that are too complex, which almost guarantee’s that they won’t work quite right for the next project.

[@TheSuperappelflap]

Invention and web apps dont go in the same sentence.

[@Cyanide300]

@@TheSuperappelflap Oh look, a time traveler from the 20th century. Neat.

[@TheSuperappelflap]

@@Cyanide300 writing frontend code in whatever js framework you use is not inventive, none of it is novel, and everyone has done it 1000 times before. Just copy paste the code from your previous project and change the color of the buttons.

[@JakeStine]

A rule-of-thumb: If you can't easily estimate it, then it qualifies as Research and Development. And it should be budgeted and planned as such. Ergo, a vast majority of software development is R&D. And at the point you know a thing well enough to easily plan and budget it, it's no longer R&D. Now it's regular production work.

[@TheSuperappelflap]

All software development is R&D. This is the most complex industry in human history and its only a bit over 50 years old. None of this is mature. A person building an airplane 50 years after the first flight was doing R&D. Thats where we are at.

[@marcsh_dev]

Lets not get too crazy. I love being a programmer because its deeply complex and almost always novel, but making rockets is likely more complex Economics is even more complex. Id argue that economics is so complex zero people understand it (portions of it, absolutely, but the the thing itself) I leave you with .:. kzbin.info/www/bejne/inmxgaCed9Fgbqs

[@JakeStine]

@@marcsh_dev Software vs. Rockets : The stakes for failure in rockets are higher. The complexity is not the issue, and in many cases likely software complexity is equally high, it's just that we don't need to understand it fully because failure is cheap. In any case, complexity is a red herring here. Complexity is not the definition of R&D. You can have perfectly complicated processes that are are well understood and predictable productions and require no research or development space, but still require exceedingly specialized talent to achieve the end result. R&D is much more accurately described as exploring unknowns, and that is often quantifiable as "things that we can't make accurate estimates for because we aren't sure how long it'll take or which way is the right way to get it done." (and to be fair, much of rocket engineering also still falls into the category)

[@Turalcar]

14:10 The main criticism I got when I worked at Google was "you disappear for a few weeks and emerge with finished code" and it does have to do with me seeing attempts at estimates as worthless.

[@mattbillenstein]

I remember telling a guy once "take your best guess and multiply by pi" - so about 3x - he thought this was absurd, so he did the whole gantt chart thing where he listed every step he could think of and then added them all together. And on that sizable project he came up about 3x short... The "multiply by pi" part is supposed to be funny, but it does illustrate the in-exactness of the entire process. Software development on big projects is chaotic; trying to estimate a chaotic process by addition (when you will even fail to list all the steps) is just kinda madness. The best strategy I've found to keeping your project more or less on schedule is to continuously cut scope and simplify. Your first version of something should be very minimal with plans to add more features and complexity in later sprints. This requires push-back on product - and often just flatly telling them "no" on things that are overly complex.

[@TheSuperappelflap]

Scope creep will happen no matter how hard you push back. They just really want to do it. You can delay them. But you cant stop it.

[@mattbillenstein]

@@TheSuperappelflap Sure, probably, and i have no qualms with adjusting the schedule appropriately. If they really want something, they have to pay or delay it to another iteration.

[@crawlingrocket116]

You forgot to mention that you should multiply by Pi to account for going in circles.

[@yinggamonkulsarapitak7948]

@@crawlingrocket116😂

[@gonzalomunoz2767]

I love the way flip does whatever the hell he wants and even leaves the evidence lol

[@josephguerassio6680]

My favorate is when something goes down and management wants an eta on how long it will take to get back up before we know what the problem is.

[@XDarkGreyX]

Classic. Turned out you had no idea what the root cause was after all and now the ETA is quadrupled.

[@ZM-dm3jg]

I estimate this project will take 1 month, plus or minus 1 year potential error

[@jozsefsebestyen8228]

In scrum the main reason for any kind of estimation is to start a conversation between the customer and the developer, to make a better understanding of the requirements. Other ways of using these estimations are just secondary "benefits"

[@RU-qv3jl]

In scrum the main reason for any kind of estimation is to bet on how long it will take so stop wasting your time and just write software.

[@kaerakh4267]

Yeah I think this is a healthy way of looking at it. So long as estimation is being used to moderate the unreasonable demands of your customer it's justified.

[@IdkMaybeShawn]

In scrum the point of estimations is to give managers a tool to pressure devs into working overtime. That's why they typically have stopped using the word "estimate" and started using the word "commitment".

[@georgehelyar]

Scrum in theory: estimate so that you can work out your velocity so that you can work out what is achievable in a sprint: Scrum in reality: estimate so that managers can make bad predictions about what will be done this quarter. Agile: don't estimate, do something small now and get fast feedback from end users, and course correct so that you build the right thing

[@timop6340]

I'd bet it is the manager(s) who wants to manage and they need simple numbers they can mess around with.

[@kevinb1594]

His is how estimates really work: Someone pulls a number out their ass -> whoever is responsible for building it either gets it done way sooner than the guesstemate and pretends like they got it done near deadline or they cram extra hours in afterhours to make the deadline so it SEEMS like the guesstemate was accurate.

[@saturdaysequalsyouth]

For me, it's a question of values and priorities. I've been on large projects that shipped on time and on budget. But most companies don't want to invest in what it takes to get there. So if they're not willing to do that then they have no choice but to accept poor planning.

[@matt-james-c]

Each DHH review is watching you gradually develop a full blown bromance.

[@andresmillsgallego814]

Former carpenter/contractor turned dev.....the amount of similarities and crossover between these two industries is unreal. Roles, strategies, mindset, etc, etc. Add to that list estimating schedules for delivery, just like building a house, building software in an agile environment is almost impossible to accurately estimate. We do our best so that a date exists, but it is largely arbitrary.

[@LogenVonSchlenz]

carpentry sounds so much more relaxing to me as a game dev, am I completely wrong and it's the same shit everywhere?

[@mage3690]

​@@LogenVonSchlenzdepends on the amount of responsibility you have. As a general contractor with any amount of responsibility, it's going to be a lot of running around at top speed feeling like you're going nowhere, but at least you're getting there quickly. As the guy running the shovel or hammer with no responsibility, I can tell you that yeah, it's pretty relaxing, all things considered. I hate it, personally (can't stand being out in the sun, especially when it's humid), but that's just a personal thing. No responsibility mode doesn't pay very well, though -- just barely above fast food rates, although standard work hours are 50 a week IME so you get a bit of overtime for your trouble.

[@tciddados]

The best part is when you get asked for an estimate, you make it, and then your boss comes back with "can we change the estimate so it matches this X dollar amount we previously hinted at the customer?" like man, at that point you're not looking for an estimation. You're looking for fabricated justification.

[@TheSuperappelflap]

At that point just tell me the number you want to write down, no, scratch that, dont even invite me to the meeting.

[@k98killer]

"Hey Flip, edit all that stuff out". Editor rebellion. It's hilarious because we know that Prime does not watch his own videos, so he'll never know when Flip is letting Prime dunk on himself.

[@thecodegangsta]

“Appetite” is actually a good way to describe what DHH means. Appetite is about saying how long you want to spend on solving a problem, with scope being flexible. I’ve run shapeup at scale and can attest to how well this concept works

[@orterves]

When business asks for estimates, I ask for business milestones - what are marketing's/finance's/product's/etc deadlines? What do they need from us for each, and how far ahead of the deadline do they need it? Then, compare the scope to the deadlines and plan out the MVP milestones required, and organise the project to deliver early and often. Estimates play a role after the roadmap is laid out, where each task is sized up and scope is prioritised or cut based on business need, risk and dependency. Far too often I get asked at the start of a 6 month+ project, "Exactly how long this will take?" and yet it's clear that the business feels they can just wing the rest of it.

[@TheSuperappelflap]

In my experience, the business cant give any milestones because they dont understand what they want or how I am supposed to do it, they just have a vague idea of something they want to do something. I have to think up and write down all the milestones and then plan the project for them. Which is good because it means I can make up whatever the fuck I want and they wont have a clue how hard Im actually working.

[@orterves]

@TheSuperappelflap yep that's how it usually goes. These days I'm responsible for my team, and keeping the business from dumping all the work on their overworked heads, so I push back

[@wtfzalgo]

14:00 is why I love my company. Complete independence, just go, do stuff, and show up with results. No matter what, how, why, where, when. Just go and do stuff.

[@elmersbalm5219]

@8:00 my insight over a failed client project is as follows: if there is a spec and budget at the beginning, more often than not, there is a high level specialist or consultant who is paid a percentage on the budget. This invariably means that they will add stuff that might interest management but creates major headaches to the developers.

[@TimothyWhiteheadzm]

I work on relatively small projects (less than a year), either new applications or modifications to existing ones. We are by and large on schedule. My own estimates for small parts of projects are usually very accurate. My most common technique is to work out how long I think it will take then double it. I find that to work very well.

[@PJacksonLink]

I really like the idea of small teams that you talk about. I heard that LISP tends to be good for helping small teams go fast.

[@bjorntrollowsky4279]

1:50 Every project in modern sw dev is novel in the negative sense of: - ppl change jobs often, at the new company you have to learn their shit on the job, so you're a junior in that sense - in many fields ppl tend to constantly change frameworks/libs, again you have to learn that shit from zero on the job - the level of abstraction and the accidental complexity is becoming really horrible, often you can only guess what the performance of that cloud sw shit will be in production, with complex software stacks where versions (actual code) keeps changing under your feet you have no clue what's exactly happening

[@TheSuperappelflap]

Sandcastles built on clouds

[@valentinrafael9201]

Budget = money allocated that *will be spent* ( no more and possibly no less ) Estimate = perceived spending on the project The estimate could be within the budget or outside the budget, but they are two distinct categories. 16:20 education 100% sucks, unless it’s math, then education is really cool, because it trains you to tackle *any* problem.

[@TheSuperappelflap]

Its still funny that Socrates figured out the best way to educate 3000 years ago but people figured sticking people in classrooms and making them memorize stuff was the way to go.

[@heisjj]

I fear not the man who has coded 10,000 apps one time. I fear the man who has coded "Hello World" 10,000 times.

[@YashTiwari-13]

Alright i hate software engineer as an academic discipline in college prof. could barely creat a functioning application couldn't code but would try to prove the seriousness of seven stages of software development lifecycle out of touch with how stuff actually works.

[@gusryan]

Here is a period 🫴 . You're welcome to insert this wherever in your comment

[@Rust_Rust_Rust]

No need for periods monke understanding beyond your comprehension once you reach enlightenment then you will truly see how periods are not needed ​@@gusryan

[@MNbenMN]

​@@gusryanDon't be stingy on the commas!

[@onlinealias622]

My professors weren’t like that, they were very smart people who were great at coding

[@TheSuperappelflap]

@@onlinealias622 One of my professors was so good at coding he managed to write an interpreter in Scala that somehow made mistakes 3 iterations deep into what was supposed to be a recursive function. Mad lad didnt actually code an iterative application, he just wrote out a finite amount of recursions. Of course I found out and after 8 hours of hunting that bug down, I presented it to him. His response: "Yeah nice find, we will fix it next year". This is when I realized i needed to drop out asap.

[@TECHN01200]

The difference between a budget and an estimate is that a budget is a top-down approach whilst an estimate is a bottom-up approach. It is the difference between a grant and an auction, especially when you have stakeholders trying to bid your estimate down. There is this idea I've had for project management for a while now where you ask your clients to put money down for a feature or a product and then prioritize off of that as it shows their revealed preference.

[@WiseWeeabo]

The only problem I have with estimates is that I assume I can use all of the time for the task..

[@techsuvara]

Software estimates work this way, the more you do on a project, the more you know how much is left to get done. I like to do some designs up front and estimate the framing, business logic and ui based on 20 years of experience, then I double it.

[@monad_tcp]

15:20 I loved diff equations, that's why I took business classes, I hated them but then I got something out of it that produce good results. diff equations and programming and business skills is a killer combo.

[@JorgetePanete]

4:30 If you wanna be my coder, you gotta get with my bugs, Make it last forever debugging never ends

[@lynwoodcallahan7286]

I could really resonate with that last part. The fact that the world works very differently to university is still something I need to adjust to

[@Algorerhythm]

Shipping the first iteration to production, because it’s “good enough for now”, also can lead to long term problems.

[@TricoliciSerghei]

Or to good insights into the current problem / project.

[@XDarkGreyX]

Everybody a victim of the system

[@oa5779]

As a former founder and career head of product, I'd suggest that "estimations" and "budgets" are probably best made by establishing what percentage of your total dev capacity you are willing to devote to solving a problem until it's solved. If it needs to be done no matter what, then the time and cost is ultimately irrelevant. If you can't do it, or can't do it cheaply enough, then your business model or funding capacity is wrong. Sometimes certain things are a good idea, but are just a bridge too far, or only work when overly subsidized by VC cash.

[@mariusj8542]

Been working as a developer for over 30 years doing mostly consultancy, and I’m not sure how many projects I have been involved with that has not have had a meeting where both parties needed sit down and renegotiate. It’s as you say, new stuff is often/ never fully defined, and both party does not fully know or realise what they need before the project is half way in.

[@litjellyfish]

working as a mix of noob coder/scripter tech artists, generel 2D / 3d UI UX artist, producer, product owner, scrum master: Biggest thing is that many of those terms and definitions how clear they are gets read differently by different people (even in same role) that is why if the product is say a game or app or something user fronting with features that is tangible to role play more and to more physical mock session, and from there more protoypes and also to always move features out of "deliverables" Also I hate when there is a discussion and people say "hey this is out of scope of this feature" and what to cut that out. No... the best way is always to look ahead a bit and then reflect back on it. Many (for me devs especially) seems to have problem with this time abstraction - just because we talk about maybe doing someting it may not happen. But if it happened what major implications could it have on the next delivery. I really big, yes then that needs to be noted at least or mayne some small things can be changed or added to the next goal to support future features. Or just cut it out. I never liked roleplays with different role hats. For me all is clients in a product. I use instead priority hats. Like if a feature is supert important, vs a nice or maybe. Also this neck sign for "now" vs "future" Many laughted at my brainstorming and design sprint meetings etc. But they always work well. I always say look to animation and movie production of the mid 30-50s they know how to get things going.

[@deathamalation]

In product development, we use estimates to try and align what we will achieve in a roadmap period. This allows us to give an indication of forecasting what we will achieve on the product in the next X period it also helps us figure out what other activities in the business will need to be communicating for the product marketing aspects in a 3-6 month period, overall helping us execute as a whole We do try to get the estimates as close as possible, but its not for budgeting purposes - if the estimates are off, we just adjust our expectations, typically they are off by a month or so in a 6 month period, which is not too bad.

[@aLpenbog]

Changing the scope is a funny idea if you are building a product you sell later on. Where it really gets hard is if you develop customer specific/adjusted software and they want a fixed price tag on it.

[@garanceadrosehn9691]

There might be one advantage in talking about "budget" instead of "time". I've had projects where I've said "oh, this is going to take 40 hours more than we expected it to". Management says "okay, we do want this project done, so sure". But then they don't really want the *deadline* to change. They'll say "okay", but then they'll say "But we *DO* need this new thing to be available before the start of the fall semester". Units of time doesn't mean anything to them.

[@onlinealias622]

Too many companies see developer overtime as free because they are salaried. 40 more hours of work split over a month doesn’t matter to them as long as you hit your deadline, regardless of the personal cost to the software engineer. That comes back to bite them in turnover, but they got their extra work in so they don’t see the issue.

[@TheSuperappelflap]

@@onlinealias622 US specific problem. Civilized countries have laws against that. In my country, the Netherlands, you can only legally work structural overtime if you are on a pay grade that justifies it. And in software development, you can make way more than managers at other places without being expected to work any overtime. I have worked maybe 3 hours of overtime in my entire career, and that was voluntary, unpaid, because I was motivated to work on something interesting. Overtime doesnt just bite them back in turnover. It reduces labor productivity. People get less done in 50 hours than they do in 40. This country has the highest labor productivity in the world. US needs better laws for workers rights.

[@TheSulross]

This all started back when Gorf was demanded by the tribal leader to provide a timeline estimate for rubbing his sticks together to start a fire for roasting a leg of Zebra - like, hey, alpha male dude, have you tried starting a fire by rubbing sticks together? We software developers - we are all Gorf

[@jasonking3248]

You solve the problem, you create it, and I take the credit for it.

[@pxkqd]

You just have to give different estimates to different people. If the engineer says 6 months, tell the manager 1 year and the client 2 years. Problem solved. We worked sooo hard to finish it 6 months earlier than we previously told you.

[@channelname785]

If that's working for you, I am glad to hear it. However, what would happen if your company was competing against the company that I just left - which does the opposite: for instance the entire team says a certain project will take at least one year, instead the client is told six months. In reality - it will take 2 years (was at 1.5 when I left). How do you compete when many companies just tell the client whatever they want to hear to get them locked into a contract?

[@TheSuperappelflap]

@@channelname785 By having a proven track record of not lowballing your tenders and finishing your projects on time. This kind of reputation is awarded a lot of points on tender reviews, well, by people who know what theyre doing. If its a government contract, ye you gotta lie.

[@PhilippBlum]

Of course they don't work. That's why we use Fibonacci story points.

[@defeqel6537]

I know story points aren't supposed to be about time, but they are in the end. Almost any estimate over 2 days will be wrong, and many estimates of 2 days will also be wrong. That's the only question that matters: can you do this in 2 days or less? If yes, great, if no, see if you can split the task (e.g. into research), or accept that you will have resources tied to a task for an undetermined time.

[@RU-qv3jl]

Why not quadratic? If no-one can explain the true reason for using a system then the system cannot be reliably reused and was probably either a fluke or not involved in success where it first garnered populatiry

[@olafbaeyens8955]

Fibonacci story points don't work either

[@PhilippBlum]

@@olafbaeyens8955 I am not very serious here.

[@olafbaeyens8955]

@@rickybobby7276 This is not the way SCRUM coaches tried to teach me ;-)

[@sealsharp]

You can have a lot of smart ideas, but a customer willing to buy something wants to know - how long it takes - how much it costs and - what exactly it will do and under which constraints and the project starts with a contract that states these things. Nice idea but i don't see customers accepting "well, just give us money and see how far we get".

[@TricoliciSerghei]

I do agree with you on this front, but code writing is just too volatile to give correct estimations.. And the most volatile factor is the client himself.. Because 150% of the time, we start with one scope and we end up with a pretty different product in the end.

[@georgehelyar]

This only really applies to bespoke software and contracting. If you're writing software that you sell to many customers over time then you don't have to agree these things up front, you have to incrementally improve the product to get more customers over time.

[@Th3T1redPanda]

​@@TricoliciSerghei because you write most of the code instead using the one you should already have. client like that has to be lead like a dog on a leash. you have to have a stable non-agile engineering process. your clients should be interviewed before any work will start. in case of business tools, a dev should go an work at the client's location, work the process the client wants to have digitalized. the client is usually not the user, has no idea about the real process, and often has idealized vision far from the truth. there is no other way. when you know what the client wants you start from most general structure - like mockup or model. ever step you add a small functionality. at end of each step you show it to the client and he decides what next. let the steps be short even two per week. this is based in psychology. the client after each step will get a surge of creativity and will get fuckload of ideas. the longer the pause between the demos the bigger the changes he will want and the more time it will cost to do the changes. small steps with small impovements will allow you to "contain" the client, make him happy, important and calm. yes, it;'s agile, but do it only between the client and you. you and your coworkers have to have the same repeatable boring process not affected by the client. measure the duration of everything you do. do not use this to grade people. use it to do the estimate for the next client (add 5-10%). use it to improve your process and to check the efficiency of your tools or claims about new tools someone wrote about on the internet. do not believe anything you read on the internet. this included. confirm everything yourself. become god.

[@chunkspiggle3916]

Tough shit, you will pay one way or another. Either a decent team for a year or two at $x/month or a bunch of indians for $0.x/month indefinitely.

[@gracjanchudziak4755]

That's the problem with the mentality, they want to b u y software and it's hard to resent that, it's just comfortable - customers put money on the table, so they can demand everything they want. The point is that this is impossible. Software is a highly abstract activity, you can speculate how long something monotonous will take, but not something volatile. It's more like witchcraft than something empirical.

[@KillianTwew]

12:00 Personally, as someone who is more of a "jack of all trades" than a "master of one", I find the difference here to be the ability to sort of deep dive a topic. If you're making many apps you likely aren't really digging into what what that subject is, you're sort of just learning the surface level and them moving onto the next subject.

[@alxyok]

so much agree on this. from start to finish. could have wrote it exactly like that ☺ stop BS, start building, figure it out, then rewrite it all better. no idea what's in the way before it actually happens. only then can you properly solve it

[@nitesh-maharaj]

I just wrapped up a (~9 months) project where we overshot our deadline by 2 weeks. But, I was able to deploy on time, toggling off the features that weren't ready to go by the deadline, turning on the missing features a couple weeks later. How did I do it? Business gave me a deadline, which I pushed back on by giving them an estimated time of completion based on rough estimations. We then renegotiated the deadline, but I cut scope from the project. I then built a flight plan with a bunch of "guesstimation" milestones, and I just needed to keep us in range of the milestones. A lot of this came from implementing what I'll call MVF (minimum viable feature), saying that we'll add in certain bits of functionality after go-live. We did go through the process of estimating every user story, and we did track velocity, but I didn't pay any attention to that. I measured success by having the team define their sprint goals and that's all I cared about. The user story effort did help the team gauge if they could or could not make the sprint goal. Therefore my conclusion is somewhere in the middle. Deadlines are essential, because budgets are a part of life. Estimations regardless of accuracy do help gauge effort in smaller time scales. When it comes to larger time scales, you just need to be flexible and able to negotiate the definition of done for every feature giving business options along the way. Here's the biggest secret to success. I lead the team as a software engineer, and we didn't let project management get involved. I had to constantly prevent the team from building a "gold-plated" solution. I understood and helped solve technical intricacies in creative ways to prevent us from burning time. When you're trying to make a deadline, you need someone who can hold the big picture in their head and constantly make technical decisions, which is something that project management can't do. PO exists to frustrate engineers and waste time. Scrap PO and let technical people lead the project and you'll decrease project failures.

[@n00bma5ter69]

Prime and DHH…I love these videos

[@StrengthOfADragon13]

Swapping the paradigm of the client from "if we can't actually deliver spend more" to "if we can't give you what you want when you want it lets change what you want" sounds right to me. It's a hard sell to get right, but it's an important part of any project. I'm in consulting and having it understood up front that the initial estimate isn't going to be right, but the better way to plan is to adjust the goal to fit the budget makes sense to me. It would definitely make a lot of clients happier to have them agree to the idea (for the most part) up front. Software projects aren't easy, and I think this addresses a core part of the problem

[@TheSuperappelflap]

Requirements are hard. Theyre not nice to haves. If the product doesnt meet the requirements, that means it does not work and cannot be shipped. The budget is whats flexible. If your requirements are so flexible that you can drop some and still have a functioning product for the customer, those arent requirements. Theyre nice to haves.

[@NotAFanMan88]

7:00 what i'm interpreting is that "if I have X amount of time, what can I accomplish to knock out what they really need?" Its when there's open-ended deadlines or a very strict scope of requirements that it ends up becoming complete nonsense. If you have a timeline of when something needs to get done, you'll find a simple way to get it done for 80% of what they need, then expand it out as time permits. What I've found is that end-users want a whole lot of little things rather than focusing on the bigger picture (which honestly, requires a redo of the entire process that they are familiar with), and if they end up getting what they want, you get distracted by all the little requirements that create an incoherent mess of garbage.

[@TheSuperappelflap]

Every deadline is open ended. Theyre more like guidelines anyway.

[@UODZU-P]

For most people what they want and what the do are different things. Especially when you are using things like social media as an example which is riddled with dark patterns to create addiction.

[@sophiophile]

I am a team of one, expected to deliver POCs on a very tight timeline. Even without giving estimates, people get pissy with me after 2 weeks, even though I'm usually juggling 2-4 at a time. I have only started pushing back, since I'm coming up to the end of probation. But it's nuts.

[@gregsmith3373]

Construction/building projects are the same way. You never really know what kind of problems you're going to run into until you break ground and start doing the work. You're going to run into weird problems you didn't anticipate. You might find infrastructure that you didn't know existed, sub-systems that you need to integrate with that you didn't know you needed to talk to etc. I think the best we can do is spend some time making a reasonable estimate, don't pad it, and just let the business know that this is a best guess and the accuracy can't be guaranteed. For most businesses this should be fine and acceptable.

[@eng3d]

It happens when the company does not have a seasoned programmer (a programmer is the person who also develops the scheduled program). If the project is not about S&R, then anyone with experience could give an estimate in time.

[@matt-k5i]

Interesting hearing this debate from a completely different perspective to mine. I work in a heavily regulated industry (think pension funds) and so we often have to update our code for compliance reasons. In those cases, the law goes in on that date and we must deliver before then. In this case, time does not equal money. We obviously have issues with scope as well which makes estimating difficult but it has to be done. Likewise for the 'do less things better'. If our project will enable a new feature/product or reduce manual labour then it goes in. A lot of scope gets creeped here for edge cases but automating that might save 50k a year if someone in operations had to manually fix it. Interesting seeing the difference between the more Silicon Valley vibe of this video vs my Aussie corporate experience.

[@AbhinavGunwant]

12:11 Good job flip!

[@t.p.2305]

Estimating can be done by this formula: time needed = time estimated * pi , if you have done a similar project, otherwise multiply with 2*pi instead of pi

[@moonasha]

as someone who follows Star Citizen... 4 years ago we were supposed to get a patch that was supposed to come out 3 years ago that was supposed to come out 1 year ago that's coming out in a few months that will come out in 4 years. This summer we got a patch that was supposed to come out in May that was delayed to June that came out in August

[@TheSuperappelflap]

Theyre just working on Valve time bro

[@thewayis_meh987]

Prime says I have to thank Flip so here it goes. Thanks Flip

[@laughingvampire7555]

I would love for you and DHH to talk about types.

[@MrHaggyy]

First i agree that time and budget are the same, linked with your salary. I think this comes down to the difference of research vs development. In research your goal is to build a catalog of buildingpieces. This kind of work does not have a predictable outcome unless it's done. So you need to work with an estimate. Development on the other hand is putting the right building pieces together for a product you want to ship in time. If your research is on point this becomes just a list of things you need to do and you can predict the end to it's day. In the real world R&D is usually the same. So your manager needs to work with both, estimates of best & worst cases as well as chaining all steps with their dependencies. In small teams you are also your own manager. That's why negotiating with your manager barely takes any time, and it's quite unlikely your miss something important. As you grow the project in size this negotiation get's more and more expensive so estimates get more and more valuable to keep everybody on the same page.

[@CottidaeSEA]

For smaller tasks I make pretty accurate estimations. For bigger ones it's pretty much impossible. There's so much that pops up in the middle of development that was simply impossible to think of when estimating how long it'll take when doing bigger tasks.

[@pieterrossouw8596]

Timelines: crystal clear on nice management-friendly Gantt charts. Scope: literally no one knows, but it somehow grows every month. Estimates: nay, commitments How many times have you been asked to estimate the time for a task then a few days before you get told you committed to it "by Friday" or something. Guess we can have another meeting clarifying the "definition of done", like the reason we're late is because we don't know what "done" looks like. Done means feet up, beer in hand, shooting the breeze... Anything else means we're not done. It's not something that neatly happens every two weeks for some arbitrarily included tasks with estimates set by people who couldn't accomplish the tasks themselves if their lives depended on it. I love software development as a craft, the industry is tripping though.

[@TheSuperappelflap]

it do be trippin

[@nano_sweet]

7:38 I think that's one of the better descritption of agile development I've ever heard.

[@oomreni5820]

Not with my managers, it's not. They basically go: "hey the client has just asked for this brand new thing. How long will this thing, that no one in the company has ever done, take you? Oh you want to think about it first? Well how about you add your estimate for how long you're going to have to think about it to your estimate for how long it will take? You have 5 minutes, or you're fired."

[@nano_sweet]

@@oomreni5820 Man that sounds horrible. So many managers use "agile" as an exuse to micro-manage team members.

[@TheSuperappelflap]

@@oomreni5820 get a different job

[@alexanderjordan2506]

When a client is ready to fork over 6, 7, 8 figures, they don't like to hear, "It'll be done when it's done."

[@flipperiflop]

Excited for the DHH interview

[@chocolate4212]

I'm glad there's finally some attention on the Shape Up methodology! We use it in my company, and while we don't do everything in it, we do most things and it's been a joy to use! I can't stand agile/scrum after years of doing it. Shape Up is much better for us! (team of 4 engineers, out of 13 people in the company)

[@Grunt-lb7vx]

My best estimate was a project where my estimate was cut by 3x original numbers (because it would not be approved by biz), at end of project it came within 0.8% or original estimate.

[@xlerb2286]

Last place I worked used T-shirt sizes and estimating only to that rather vague level worked fairly well for us most of the time. And that I think is about as good as it gets :)

[@rnts08]

Breaking news, parrot learned the phrase "Hows the project going?". Gets hired as project manager at $company.

[@MrLordLowbob]

I do like watching actual programming content, its just that I can only enjoy it if I actually focus my attention on it to understand the thoughts that go into it. while most article reads, I have them on headphones while doing other stuff and you can mostly follow along with only half a braincell allowing me to do it in my spare freetime without giving up other activities that are also important to me.

[@joelinman6455]

I use the ‘Pi Reality’ formula in my estimates. Whatever you think it will cost or however long you think it will take. Take that value and times it by Pi … you are now closer to ‘Reality’!

[@Adamskyization]

That's one of my main as a software engineer freelancer when talking with clients

[@stevezelaznik5872]

We tried DHH’s “shape up” methodology at an old job. Following it to the letter was insane. We scrapped features that were mere days from completion because we had hit the 6 week mark. “Ope, this sprint failed! Oh well, time to move onto the next thing.” It’s been a few years so I don’t remember the details of Shape Up methodology anymore, but it didn’t seem to be any better than what was out there. DHH is a lot like the postmodern academics of the 20th century. They point out the flaws in the status quo and then fail to provide a better alternative.

[@deepakkumarmeena1890]

you spew random words in my ears while i think about something else is what i want

[@marcsh_dev]

I love this discussion, but I feel like for 40 years its been the same one Yet, Ill go in to a new job, and talk with senior project management, as well as leads from other departments and we'll talk about exactly this. That detailed planning never work, and that we'll approach it from another angle . . ... . . . and then 2 weeks later we're talking about exact demo dates with full feature sets. Hit this so many times

[@Fanmade1b]

Estimations != budget The best products/projects I've worked on were done like this: - Describe hat do you want - create very small tasks describing what needs to be done - sort these tasks by relevance The top tasks should then be describing the MVP that needs to be finished to have a working product. Everything after that are optional features. While the tasks are completed from top to bottom, the latest version is always available for testing and feedback. This feedback is always integrated into the task list and it is always ordered by relevance. If the MVP can't be finished before the budget runs out, the budget was way too low, or too much irrelevant stuff was prioritized. Estimations mean: "We would like to stop working and instead think about how long it might take you to actually work on that thing with the current plan that will change anyway the minute you started coding. Oh, and we will totally plan our road map based on your estimations, so if you estimate to low, that will mean a very stressful time for you. So you better multiply your estimations by ten before telling us and then if you're done earlier, you better just keep it a secret and only push your changes shortly before your estimated time expires, or otherwise we will totally just cut your original estimations in half if you deliver too early too often. So there is no benefit in estimating things, but a lot of disadvantages. Let's do that in 90% of all projects then! "

[@Sonsequence]

"isn't that just a truism?" Prime, if that's your normal experience you're lucky. DHH is talking about an management attitude that's hungry to _cut_ requirements along the way. Most managers get very wedded to their initial vision.

[@wagnermoreira786]

I'm curious to see the video where DHH came in to talk about these things, where is it?

[@drdeus-u8s]

The main problem with estimates is that the pm’s will always tell you that they’re just rough estimates and that you are rating complexity not time. But then they hold you to those estimates like it’s a contract

[@TheSuperappelflap]

"Points dont equal hours" is a running joke for a reason.

[@bakenbard]

11:10 - timed out for 7 seconds. Reason: elixir mentioned. You son of a... I'm calling José!

[@notapplicable7292]

The lack of independence is by far the biggest issue I have with many new engineers.

[@Sonsequence]

When he says "novel" he means that if you know what you're doing, everything non-novel in your CRUD app will be left up to frameworks and libraries.

[@perz1val]

Thank you flip, you're the boy

[@daven9536]

I have learned to dramatically overestimate to the point where i only miss the deadline by a couple of months ...

[@writeorwrong88]

The word you're looking for here, "what you want vs what you say you want", is "revealed preference".

[@coreyspeisman3941]

I think it's fascinating that people dismiss XP and agile and then go on to come up with "new" approaches that are the core fundamental ethos of XP and agile. What DHH is describing is small empowered teams, building and delivering incrementally, and learning as you go. Avoiding BDUF, set scopes and delivery dates.