16 ms·
“I’ll Finish It This Week” and Other Lies
- deleted 6y ago[deleted]
- dstein64 6y ago> "Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law" - Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p. 152. https://en.wikipedia.org/wiki/Hofstadter%27s_law https://en.wikipedia.org/wiki/Hofstadter%27s_law
- jxy 6y agoHofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
- wunderflix 6y ago> So, what did we learn? 1. If you are coding or writing, multiply the expected time of any specific task by ∼ 1.5x (the real completion time will now probably still be 1.5x longer than your new expected time, but you tried). 1.5x matches my real-world SW dev experience.
- vishnugupta 6y agoI read somewhere that a rule of thumb is to double the number and then scale it up by one order of magnitude. Example: 1 day == 2 weeks, 1 week = 2 months, 1 month = 2 years. More than a month = Let’s not even start.
- curuinor 6y agoit's all fat tails, they're all fat tails, assume correlational structure and whack peeps in the head if they say anything about bell curves when you play the game of code you play a demonic St. Petersburg martingale. you start with one time period. flip the coin- heads, you finish. tails, you double the time period. at the end of that time period, flip it again: heads, you finish. tails you double the time period again. and so on: the expectation is infinite. "well, that doesn't sound so bad, really" - there's why bernoulli was scratching his head.
- Thorrez 6y ago> I said a 8 but I don’t really know why > Could be a 1 or it could take my whole life https://www.youtube.com/watch?v=sh7A8UChBTI https://www.youtube.com/watch?v=sh7A8UChBTI
- bick_nyers 6y agoI didn't know this existed. Thank you
- deleted 6y ago[deleted]
- halayli 6y agoimo, the problem with estimates vs reality is that estimates don't include mental state. And just to clarify more about mental state, I am referring to being in the zone / flow, and individuals are healthy and experience normal stress / happiness levels. We assume and expect consistent productivity from ourselves. Anecdotally, In my 20 yrs experience, I've never heard a software engineer saying to their manager "add 2 more weeks on top because my mental state is not at its sharpest these days". No SE in their right mind would put themselves in such a vulnerable situation especially when no one else talks about it. The delays we naively anticipate are the obvious technical related ones and gotchas / cases we might not have considered for the problem. This is a problem that is prominent in this field and unless I've been missing out on discussions, I've never seen it discussed. There is a huge productivity difference between people that wake up in the zone vs any other zone. And I've yet to see an SE or any other human that can wake up in the zone every single day. It's impossible. Although this is something we can improve at an individual level by focusing on lowering the std deviation which will help us estimate better and imo it's one of the key factors why some SEs can give more accurate estimates than others assuming they have similar technical skillset. Each SE deals with this fluctuation / "problem" alone. I've often seen SEs jumping on the management track when the gap between "being in the zone" start to consistently widen. Often after a burnout that never fully recovered. You wouldn't see this being a problem in careers like HR/Management/Sales. Because an individual can still be somehow productive without being in the zone. But in software engineering, art, writing and the like, it's kind of binary and is very visible.
- hmwhy 6y agoI'm not sure the metal state that you are referring to really makes a difference in terms of deadline estimation. The way I see it is that, in the grand scheme of things, if you are consistently missing the targets then either you get fired or, if the problem is systemic, the company folds. In other words, if you are not getting fired and the company isn't folding, and that neither is happening anytime soon, then everything is just "business as usual" and missing a deadline here and there is just part of the natural statistical fluctuations that everyone have come to accept according to some unwritten rules. I would go as far as drawing parallels between "being in the zone" for a software engineer and "meeting sales targets" for a salesperson. In that sense, not being in the zone every now and then is just as reasonable (or unreasonable, depending on your employer) as missing sales targets every now and then.
- rognjen 6y agoAn important thing I've learnt is that people over-estimate what they can do in a short time whereas they under-estimate what they can do in a long time. You probably wont finish that feature tonight, and that's OK. But you will have built something good in a year if you work on it a little bit consistently.
- deleted 6y ago[deleted]
- js8 6y agoI feel like people underestimate the time something will take but overestimate the actual effort. What you say seems to be a consequence of that. We underestimate the time, because in reality we often worry about things, and procrastinate on decisions. But in the estimate we don't think about it, we assume all decisions will be made immediately. We overestimate the effort, because we sometimes do not know how to solve certain problems or work efficiently and in the estimate, we only know the hard way, not the easy way. But with practice, the hard way often becomes easy. It might also come down to us valuing future work more than the work in the past, so looking back things are less effort than looking forward. But in the case of time itself (represented by hit/missed deadlines) we value these as more important with respect to the past than to the future (they already happened, while the future is uncertain).
- spaetzleesser 6y agoThat's one of the big problems I see with enterprise agile development. Breaking up things into small independent parts never allows you to gain momentum on something. Pretty much everything I did that I am still proud of were done after focusing on the an issue for weeks or months until I/we had a very good grasp of the issue and built up the mental and code infrastructure to do cool things. You can't achieve this in 3 week sprints.
- xcambar 6y agoEstimates are here to fail, but they're nonetheless crucial: * set an estimate, you'll deliver in 1.5x your estimate * don't set an estimate, you're losing total control over delivery (rarely for the better, even though that may happen) In other words, estimates are not a tool of delivery planning, but of risk management : they are here to help limit time dilation.
- DoingIsLearning 6y agoI will paraphrase a former Japanese manager who taught me a lot about designing for production: "Plans will always fail but we must always have plans."
- splittingTimes 6y agoOver the years our team has gotten good at grooming and splitting up tickets, at estimating individual tickets and keeping a steady Sprint velocity. Each 3 week Sprint we deliver what the team commits itself to. However on a macro level we fail spectacularly. Initial Roadmap estimation of how long new features take are way off. A new feature should be ready in 3 sprints.. make that 6. This milestone should be reached in 2 sprints.. Make that 4. It often comes down to hidden requirements that are discovered midway or prototypes that get into feedback loops with stake holders and take much longer then expected. Compared to those problems, we Rather seldomly we hit unexpected technical problems that prolong a project (but of course this happens too)
- TameAntelope 6y agoThis here is why requirements need to be use case oriented, not code oriented. “I want to be able to look at my user profile” not, “I need to click on my user profile picture and navigate to a page displaying the following ten items...” There needs to be room to deliver the value that can take on that uncertainty. It’s a good thing when an engineer can take a look at the use case and have options for how to deliver it, if you hired for that.
- js8 6y agoIf you focus on short-term, it's somewhat unsurprising that you fail at long-term.
- TheCoelacanth 6y agoDoes the roadmap include 1 sprint blocked off for unknowns for every 1 sprint that is full of known tickets (actual ratio should be determined empirically for your team)? If not, I think I've spotted your problem.
- tpoacher 6y agoHonest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, then cut corners to deliver a finished project in two weeks, but one that is so lacking that someone (possibly not you) will need at least 4 more weeks undoing and fixing stuff at a later stage? (Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b)
- ohgodplsno 6y ago> Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b) So, you've never seen someone being a professional ? I've told my boss plenty of times his estimates are wrong, and that it will take longer. It's my job to know how long things take. If my boss thinks it can be done shorter, he better 1/ have the same work experience that I do and 2/ do it on his own.
- zepolen 6y agod) Tell your boss it will take 6 weeks, deliver in 4
- pmiller2 6y agoI see you're from the Montgomery Scott school of estimation.
- irjustin 6y agoWhere's D where we talk it out and why we currently disagree on the expectation difference? Isn't that how it's supposed to be?
- wccrawford 6y agoFor me, it's not even that. I've never had a boss tell me what it'll take. I've always been asked, even though I've repeatedly told them I'm horrible at estimates. Thought sometimes they'll suggest a timeframe, hopefully. When I tell them that they were too optimistic, their usual reply is that I need to get back to them as soon as anything changes for the worse. Otherwise, truck along and do it. If I say 'nope, 4 weeks' right off the bat, there's usually a step where they consider if it'll be worth it in that time (or possibly longer) and they tell me when to ditch it and move on, if it's really going to be that long. And it happens sometimes, even on projects that I really wanted to do. The opposite happens, too, though. Sometimes they think it'll take longer than I think, and I tell them in that situation, too.
- camilo86 6y agoreminds me of "cheap, fast, good; pick 2"
- euroderf 6y agoThis has been formalized in a triangular graphic. Why not provide this to a project manager, on a corkboard or magnetic board, along with pins/markers to show original plans and current estimates ?
- robjan 6y agoThere's another dimension which is "scope" and is also often negotiable.
- layer8 6y agoDoesn’t non-fast imply non-cheap?
- claudiulodro 6y agoIf I understood your question, cheap + good + slow is generally when you do everything yourself.
- layer8 6y agoI guess it depends on your salary. ;) The way it makes more sense to me is when you spread out the same amount of effort over longer elapsed time, quality increases just my not rushing things and being able to reflect more.
- dredmorbius 6y ago"Cheap" == billable time * per-worker capital and support, not elapsed time. Obviously, if a given workforce on a time-based compensation consumes more billable time units, they will cost more. That isn't the general case envisioned by the GFC triad, but rather that additional resources (bodies, brains, greater talent, tools, extended workdays or weeks) be applied. Classically, The Mythical Man Month. Accrued technical debt is another (often hidden) cost. Good / Fast / Cheap is a possibility / optimisation frontier. When you are at the frontier, you cannot optimise any one third factor without sacrificing one of the other two. An obvious countertactic in negotiation is to argue that the task is not yet at the frontier / optimum. In practice, this may be true, though the frontier may still lie far closer than such tacticians generally seem to posit.
- eyelidlessness 6y agoEstimates are bad because everyone is preconditioned to lie and don’t want to hear the truth.
- pmiller2 6y agoHmm, who knew that if I had just paid good enough attention at my team's standups, I could have gotten a publishable paper out of it. This isn't sarcasm. I'm actually glad someone did it.
- jokoon 6y agoI interacted in a workshop with a person who taught about personal organization, and we had a phone session. I thought that it was important to fill your planning and calendar with fixed things. Instead she advised me to just plan week by week. I'm a freelance and honestly, it sort of feel better to be part of a bigger, organized group that tells you the things that are to do. When you're the only decider of your own planning, it feels really weird: do I just have to fill up my planning with whatever things I deem of importance? Just like Sartre said, we are shockingly free (existentialism etc), and we still crave and aspire to be part of an organized group with goals we can adhere to, to feel safe.
- dkarl 6y agoI agree; regimenting your day is a poor substitute for short-term planning. It looks very orderly to have items like 9:00am, read email, 9:10am, Make sure Jira tickets are in correct states, 9:20am, respond to email, etc., filling your calendar from now until eternity, but it makes more sense to spend ten minutes at the end of every day planning the start of the next. Maybe you know your Jira tickets and email are in order and you can sleep an extra half hour. Maybe you have an important presentation in the afternoon and it would be best to spend 8am-9am nailing down the answer to a question you know will come up. It's very hard but very important to stop working a few minutes early at the end of the day. You want to keep coding (or whatever) right up until the minute you need to stop, but that leaves you unknowingly disoriented at the start of the next day. You will either pick right back up with the coding, forgetting about everything else, or start aimlessly and waste the first hour of the morning trying to restore your awareness of priorities.
- tobr 6y agoI like the use of “spoiler” in the abstract. I mean, that’s basically what an abstract is.
- bluenose69 6y agoI wish they had plotted those time-series graphs with simple lines, instead of with overlapping filled curves that hide the initial history for data plotted "underneath". Has MIT changed from a technical institute to a business school, where pretty colors matter more than the conveyance of information?
- thrower123 6y agoIf you can escape from the constant firefighting of interrupt-driven work, you can finish things on a predictable schedule. Unfortunately, you log on to work on X, and it turns out customer A had a sev 1 outage, and youve got to scramble. Maybe once that is resolved, you can get back to X tomorrow. Except tomorrow, customer B reports some other bug, and you're dragged into triaging and reproducing that, while its still fresh. Now it's Wednesday, and you get one day to work on X. Thursday rolls around, and your day gets chewed up by another handful of meetings and status checks with A and B, also C came in with something. On Friday, you're worn out and reeling, and you realize project X never really got off the ground. Rinse and repeat until things just fall through the cracks.
- sublimefire 6y ago"Never commit to deadlines" -some software engineer Software has an unbounded set of problems, like in the creative fields. The difference is that you can fill in a book with random thoughts (if there is no time), but you cannot just fill in functional features in the codebase you did commit to. The same issue exists in the very large and complicated builds (eg skyscrapers) although you can plan ahead really far due to the existing physical constraints (site size, machinery, materials, avg. labour output). Over in the software shop I work for, we just prioritize each week. Works really well. And we cannot commit to the deadlines or even estimate, as there are too many moving parts, too many products. To make customers happy the product managers comfort them with words (just like sales people promise mountains of gold for a penny).