30 ms·

Deadlines are pointless – what to do instead

186 points by lucasfcosta 4y ago

osigurdson 4y ago
TLDR >> Preemption points are regular time intervals at which the team will review a task’s progress and decide whether they should cut scope, change their strategy, or drop the task and cut losses altogether.
- layer8 4y ago
  That definition is too abstract for me. If there is no deadline, why would one cut scope or drop the task? Conversely, why do I need preemption points to decide to cut scope, change strategy or drop the task? Usually the realization/decision comes naturally during implementation, without needing artificial occasions at constant intervals.
hknmtt 4y ago
In my last two jobs I refused to have deadlines. It's done when it's done and there is no one that can do anything about it. Companies need to accept this.
- hinkley 4y ago
  There’s some value in giving constraints to junior developers. There’s some value in getting senior devs to look at the calendar and re evaluate their plans. Estimates can trigger both of these, but they trigger bad consequences as well. Personally I’ve found that an engaged boss who I respect and occasionally points out I’ve sure been working on X for a while, is everything okay? To be at least as helpful as schedules. But if I could figure out how to get that consistently, I’d be on a book tour instead of keeping an eye on some people doing a deployment while I should be in bed.
  - Akronymus 4y ago
    I am somewhat of a junior dev. Without deadlines I have a LOT of trouble keeping on task.
    - astura 4y ago
      This is really common and I expect it from my Jr devs and plan accordingly. So don't feel bad for it (not that you said you did).
      - hinkley 4y ago
        What we never ever learn is that never doing something is not an antidote for doing it all the time. It’s just exchanging one stupid extreme for another. My suspicion is that it has something to do with learning the wrong lessons from Boolean logic. The principle of the excluded middle applies to bits, not process.
- treeman79 4y ago
  Senior developer will be able to offer a range of options. X in year. Y in a month. Z in a day. Etc. Maybe Z is good enough. Maybe only X is.
- heurisko 4y ago
  You would have been removed from the project I was working on, which was responding to a governmental regulatory deadline.
est 4y ago
I think deadlines are really tech debit & credit, it's useless in a technological sense but a driving force business-wise.
PragmaticPulp 4y ago
It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason. That might be moderately true for, say, someone developing a new app feature that gets shipped to users who aren’t expecting it. However, it’s not true at all when the software development output is a gating feature for real-world contractual obligations and other such business drivers. In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain. This doesn’t guarantee that a target date will be hit, of course, but it’s not impossible to produce estimates that are reasonable accurate a large percentage of the time. Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible. I suspect many of the developers who believe that target dates are always arbitrary, pointless, and impossible to estimate have mostly worked in big cash-rich environments where it didn’t really matter when a feature shipped. If you go to the other end of the spectrum and talk to engineers who work in industries where target dates are critical you’ll discover a lot of people who are very good at breaking down projects and accurately estimating dates without relying on crunch time to get things done. It may sound impossible if you’ve never worked in an industry that requires such precision, but it makes sense after you’ve worked in such an environment for a while.
- bagels 4y ago
  When your software is a piece of a much larger, expensive real-world project, deadlines are not pointless. Imagine, for instance, writing software for an interplanetary probe with a short launch window. Pretty different from writing the 'Yo' app.
- arnvald 4y ago
  Most deadlines in my career so far were arbitrary. Sure, some deadlines were driven by fixed events, for example Christmas promotion has to be launched before Christmas. But in most cases when I asked managers about the reason behind the deadline, the answer was something like "oh,I promised this team/director we'll do it by then". When I dug deeper to see what happens if we miss the deadline, it appeared the said team would be just fine, there were no real life consequences, just that they wanted to finish their part of work by certain time, and they depended on us. I'm not saying deadlines are useless, but they're very often driven by some arbitrary promises made by managers before even consulting developers about the complexity of work to be done.
650REDHAIR 4y ago
Without a deadline I do not function well.
- and-not-drew 4y ago
  Parkinson's Law - "work expands so as to fill the time available for its completion." https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
  - mellavora 4y ago
    Yes. Which is why it is nice to have deadlines. As several people have mentioned above, it limits scope.
aspyct 4y ago
I would rather have deadlines than give estimates. A deadline is a clear moment in time when the feature is needed. There's a reason behind it. "We need to be ready for event X", "Next billing period is in a week". Fixed deadlines allow you to negotiate the content of the feature, and make meaningful choices when it comes to the amount of details and edge cases to handle. Otherwise how are you supposed to estimate something? I can make you the same feature in a week or in a month. It's going to be more polished in a month, of course, but I can squeeze it in a week if needed, with limitations. Embrace deadlines, you will love them.
- miriam_catira 4y ago
  This. Fixed deadlines based on real, immutable events. My current role had flexible deadlines. It makes me crazy. All that allows for as unchecked scope creep. So I can't estimate, because the teams requesting the work refuse to define a project's final state (or are incapable?) and it's often impossible to make arbitrary deadlines because they're not real either. I get almost nothing shipped. And when I do, it's literally $7k over or $6k under!
- UK-AL 4y ago
  Real hard deadlines aren't that common in real life except in a subset of industries. What people want estimates for is budget reasons. They want to lock down both scope and time. So if you want to start removing edge cases and details you'll often find they don't want to do that either.
  - aspyct 4y ago
    Most of my work, in two very different lines of work, is bound to strict hard deadlines. As I mentioned, those are events, reports to external entities, billing etc... I'd say 75% of my dev work is hard deadlines.
- commandlinefan 4y ago
  > I would rather have deadlines than give estimates Well, in reality, estimates are deadlines that they want you to feel like you came up with in the first place. You don't have to play that game very many times before you realize that they ask for an estimate, then try to argue the estimate down to whatever they had actually budgeted in the first place - but make it seem like it was your commitment in the first place.
proc0 4y ago
Deadline or not, I think you still want a prediction of when something lands for many reasons. In my experience most deadlines are set based on initial estimates (which often include technical feedback), but then those estimates get locked in because of advertising/marketing and setting customer expectations. In my opinion the biggest problem is not understanding that estimates are constantly changing based on continuous change of information as the project is worked on. Also, I've rarely been in a team that takes the time to define a unit of work, which is relative to the stream of work that is done. Breaking things down into work units allows consistent measurement relative to who works on it, and then allows for pretty accurate relative estimates, which is good enough to predict completion dates. I suspect this is harder to manage, but if done right, predicting the completion date accurately (despite any deadline) is a necessary step to then speed up that process.
- commandlinefan 4y ago
  > you still want a prediction of when something lands That's the problem. Of course you want that. Everybody would want that. Our lives would be easier if we always knew exactly when something would be finished and how much it would cost. What you don't seem to recognize is that if predictions could be made with that kind of accuracy... you could be replaced with a spreadsheet. The only reason you're still around is because our work is inherently unpredictable.
  - proc0 4y ago
    Right, but eventually you have to lock it in, or there would be no point in announcing a release date or letting your customers know when to expect it. While I like the idea of never worrying about any kind of completion date, I would think it's better for business to set customer expectations. Of course it backfires if you don't hit that date, but not having one could also backfire if when the project is done no one cares to use it anymore. For me it starts with predicting accurately units of work, regardless of desired completion date. Then work with that to speed things up if needed, and use that information for estimation.
awb 4y ago
Semi-related recent This American Life Podcast about deadlines: https://www.thisamericanlife.org/776/i-work-better-on-deadline https://www.thisamericanlife.org/776/i-work-better-on-deadli...
lisper 4y ago
I like deadlines because they help me decide how to prioritize my time. I think the problem with deadlines is not the deadlines per se but how people think about them. I think most people think of a deadline as a time by which something needs to be done or something horrible will happen. I think of a deadline as a time by which if I get it done something good will happen (my customer will be happy). It amounts to the same thing, but focusing on the kudos I'll get if it's done on time vs the (usually imagined) catastrophe if I don't makes a world of difference.
boffinism 4y ago
This whole article feels like it was written by someone who never really stopped to understand what deadlines are or why they exist. The author was only concerned with how they impact them, and desperate to push back. For one thing: "In a system that awards bonuses to those who reach a $50,000 deadline..." Not a deadline.
- beckingz 4y ago
  $50k by end of month is a sales goal with a deadline?
Test0129 4y ago
Absolutely anything is better than sprint pointing. This garbage process was adopted from what I can only assume is some cabal of "agile consultants". I have over 10 years in the industry. I cannot estimate something with less than a 20% margin. An estimate requires you to know everything up front, at that moment, for it to be accurate. Anyone who has made software knows this is never the case. The only thing it allows, and what I can assume is the only reason it continues, is because it's a job creation program for "agile certified" project managers and it produces a nice burn down/up chart you can show the manager. Sure, you can call points deadlines, but they are not. It's an arbitrary measurement of a unit of work that in total makes up a two week "deadline". Two weeks isn't enough to produce good code on anything more complicated than a boilerplate application. Deadlines are far better. Tell me something needs to be done by next month it will be done. I can negotiate inside these bounds to prevent scope creep because a deadline is far more flexible than points. If you find yourself done with deadline work, you can refine and add touch ups. If you find yourself done with pointed work the PM will just assign you more work to "keep your points up" instead of allowing you to do the same. The tyranny of the agile PM hinges on convoluted point systems. Even the one the writer prescribes. Force the management to actually agree on a deadline that is reasonable (not ship me facebook next week) and watch how productive and accurate developers can actually be. Read the comments here. Agile has been butchered to the point it's unrecognizable. Give me deadlines.
- AussieWog93 4y ago
  100% this. No matter how arbitrary and irrational deadlines might seem, they at least work somewhat well.
- FrankyHollywood 4y ago
  exactly my experience, a reasonable deadline defines the design and scoping, and makes you give right expectations to a customer. I left 2 jobs because of rigid scrum, couldn't handle the insane discussions. "how many complexity points do you estimate?" "euh, what was our velocity?" "no, you can't think in hours, give me complexity POINTS!" "I dunno, probably 2 to 3 weeks of work, to many unknowns" "unknowns? we refined this story, there are no unknowns!" "ok, 3 weeks = x points" "no, you can't say 3 weeks, we have 2 week sprints. You should split the story in 2, where each story is a well defined functional component which we can show in next demo".... "but, it is 1 thing, you can't split and have it working for next demo..." mind torture... so I left Nowadays I have a very experienced team. We do daily standups (without a scrumboard, just real conversation), we define deadlines, can be a week, can be 2 months. Demo's only when needed, kind of the way I used to work before rise of scrum :)
tsimionescu 4y ago
This article seems based on the flimsiest logic, or on experience in extremely dysfunctional organizations. > When teams miss a deadline, it’s too late to take any productive actions. > Think about the actions you can take once your team misses a deadline: > 1. Set a new deadline > 2. Fire someone > 3. Cut scope Obviously, if you only discover that you missed the deadline on the day it passes, you can't do anything productive about it. But no one (competent) works like that: you adjust your work and your scope based on the deadline for the entire duration of the project. Starting from basic design ("we need to ship this feature in 2 weeks" will lead to a different design than "we need to ship this feature in 3 months") to design/scope adjustments ("we've been working for one week and we can see this is not going to finish in one more week, do you want us to adjust the scope/design, or is it preferable to push the date further out?"). I suspect a root cause of this problem is the following idea, from the "Queueing disciplines section": > We can model every software development process as a queueing system. In such a system, tasks come in on one end, and software comes out on the other. This is a fundamental misunderstanding of how software development works, at least for the vast majority of cases. Tasks are not an input of the software development process, feature requests are. Tasks are an intermediate output - you have to put in work to refine vague feature requests into concrete tasks. The same feature request can be translated into many different tasks, depending on various factors (competition, expected timeline, team experience, external dependencies etc.). For a concrete example, say the team is working on building an alternative to Wireshark (a packet capture and analysis tool). A PM may ask the team to add support for QUIC to the product. In the ideal case, the tool would be able to understand every kind of QUIC packet, partially recognize some of the more common malformed packets, support decryption of the contents via one or more popular key logging formats etc. But, depending on product architecture, this may take half a year to fully implement. If the PM desires some minimal support for QUIC in, say, 2 months (perhaps to coincide with some fiscal quarter), then they need to work with the team today to find a meaningful subset of features that can be implemented and delivered in ~2 months. Of course, during those two months, the team may discover that they are working faster or slower than anticipated, and may need to adjust the scope even more. Even so, the deadline may still be missed of course (say, one of the lead developers falls ill two weeks before the deadline, or a fundamental misunderstanding of the protocol that was causing sporadic bugs is understood only 1 week before). However, if the PM only added a "support QUIC" "task" to the team's queue, with high priority, the team will almost certainly have nothing even close to releasable 2 months after the request was added, even if they are working at the exact same pace - since they focused on a more advanced version of the feature. Even if they are internally working in a way where they avoid having non-releasable features for such a long time, they are very likely to have prioritized other aspects of the feature than what the PM needed, and have only finished and polished those by the (unknown to them) 2 month "deadline".
mikessoft_gmail 4y ago
good and usefull article
nottorp 4y ago
Again Joel had something insightful years ago. https://www.joelonsoftware.com/2006/08/10/the-identity-management-method/ https://www.joelonsoftware.com/2006/08/10/the-identity-manag... He was sort of leaning towards April 2007; I was sort of leaning towards December 2006. [snip] What I explained to Brett, though, is that we want to hire six new people in the spring, and the chances that we’ll be able to afford them without FogBugz 6.0 are much smaller. There are deadlines and deadlines.
smallstepforman 4y ago
In the embedded world, there are hardware teams, software teams, externel suppliers, contractors, marketing, trade shows, etc. Deadlines are a real thing, and dozens of teams are effected. If you cannot schedule and execute properly, you are out of your league. As a professional engineer, I stand and stake my reputation on meeting agreed deadlines. Otherwise, it’s a sign of amatuer work or even worse, unprofessionalism. I’m cursed/blessed with an Engineering mindset, and expect the same from my peers.
- mobiuscog 4y ago
  I suspect you also have detailed specifications and requirements to allow estimation and planning. Outside of hardware-based environments, this is often missing and engineers that push for it are dropped because they are not 'autonomous' enough.
Joel_Mckay 4y ago
In general, constraining the estimated time to completion can telegraph redundancy is necessitated in a complex project. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_... Or from another perspective, the probability a given team can successfully finish a key project deliverable diminishes after a projected time. If the hard parts of a problem still remain, the progress has in fact stopped when resources start being diverted to non-critical tasks. The statistics indicate if a person says they are 95% certain, they are in fact 60% certain, and unaware of their bias. Good luck convincing the Dev-ops crowd though... being busy means progress to some folks. ;)
unfamiliar 4y ago
> A system will produce what it can produce, regardless of whether you set a goal. This is just fundamentally not true for human beings. Certainly not for all of them; I know personally I need a bit of time pressure to perform my best.
taubek 4y ago
If you are building a software (or anything else for that matter) for a specific event that has a starting date carved in stone then you can't avoid deadlines. Take some sporting event for example. Let's say F1 competition. You must have racing car ready by the start of the season. Having it ready two weeks latter is not an option.
satisfice 4y ago
I use deadlines as a heuristic. Without them I have a hard time focusing my work at all. That doesn’t mean I let myself be abused by arbitrary deadlines. Deadlines are useful to me, however I have always advocated the use of periodic check-ins to give us a chance to adjust our course. It’s weird when people make claims that are so easily shown to be wrong, as this author does, except some of that might be him using “deadline” to mean something less heuristic and more draconian than I do. I published a regular feature in IEEE Computer magazine for 12 months. I never missed a deadline. But the way I did it was by using a series of fake deadlines (up to three). I asked the editor not to tell me what the real deadlines were. I missed at most two of the fake deadlines during that year. The system worked well for me because I don’t like to stop daydreaming until the last minute. Daydreaming and playing are divergent activities that generate value; but convergent activities are needed to actually deliver.
6stringmerc 4y ago
Either you make peace with deadlines, or get your ass out of the kitchen. Seriously. I work in proposals and deadlines are not negotiable - well, unless the solicitor changes the deadline, but it’s up to them. Whining about the pressure that comes with deadlines is pathetic to me, because I make my living whipping people into shape to deliver on time. I have all the accountability and none of the authority in my role - sound familiar to software engineers? The difference is that my deadline work is people management and software is working with a machine that does what you tell it to do. People don’t do what you tell them to do, at least not consistently. They try, but unless it’s a priority, it’s hit or miss. The reality is you have deadlines because your customers have deadlines and problems they need solved. If your sales team and executive leadership consistently puts you in positions where it’s difficult to succeed at what you are capable of doing, start your exit plan. Just because shit managers push their terrible deals downward doesn’t mean the system is at fault. Deadlines are healthy to keep progress and be able to move on to another new challenge. Besides, we humans are on a deadline to get all our living done. It’s as ingrained as yelling at clouds or tilting at windmills. Get busy livin’ or get busy dyin’
- Tainnor 4y ago
  I have never yet seen a software team, team lead, engineering manager, etc. that knew how to estimate accurately how much time a large software project will take. I have repeatedly seen people saying things like "the rewrite will only take a year", "we'll have this done in two months", etc. which turned out to be wrong by orders of magnitude. I really think that, unless we're doing very repetitive stuff, the best we can do is give rough estimates on small deliverables, i.e. stories in a sprint. If what you write is true - deadlines are important - and what I write is true - it's almost impossible to estimate how long it takes to develop complex software - then there's a mismatch that needs to be addressed somehow. I thought that this was what Scrum was designed to solve (by continuously updating estimates), but you seem to think that we need harder deadlines. If so, I'm not convinced that this is actually feasible in most cases.
- maeln 4y ago
  > The reality is you have deadlines because your customers have deadlines and problems they need solved. And this is actually part of the issue (and in part what the article mention). Most project, including the one of the clients don't need deadlines. I never saw a project where the deadline was not arbitrary or govern by another project deadline who was also arbitrary. I also worked in many different context, some with hard deadline, some with 0 deadline. Almost all the time, the project with hard deadline stem from the fact that the management didn't trust their engineer. They taught that without this "pressure" we would just sit on our asses and not do anything. While I certainly encounter co-worker who would gladly not do a thing and be paid, almost every engineer I worked with was happy to work and took some pride in his job. The no deadline / soft deadline project usually faired much better with a much more happy team and client. First off there was a mutual trust between management and the team "on the ground". They trusted us to do our job and we trusted them to steer the project direction and give priority. This made the job just that much more satisfying. Secondly, there was almost never a period of rush / crunch. It could happen that we had to rush a feature, but it was infrequent, short lived, and never to the extent of putting an all nighter. This means that the team had a very consistent and predictable productivity, we didn't have any burnout and people where not likely to leave in the middle of the project, so we were never short staffed out of nowhere.
bambax 4y ago
Funny that the article doesn't even reference the most famous quote by Duke Ellington: "I don't need time. What I need is a deadline." Sure, deadlines add "pressure". But we can't wait forever for something to exist. A feature needs to be shipped at some point.
jillesvangurp 4y ago
Always reminds me of the famous Douglas Adams quote: “I love deadlines. I love the whooshing noise they make as they go by.” In seriousness, the author is right. Deadlines don't work as a tool to coerce people to work faster/better. Unless you have a detailed plan to get there; in which case the deadline is less important. It's just the last step of the plan. You'll know long before the deadline whether you are on track. Scrambling a few days before the deadline when you realize you are definitely not going to make it is probably doing more damage than good. And there's only so much that you can pull off in a few days. Doing that means you've already failed and you are just trying to cover it up. A useful tool to get out of a deadline driven / firefighting style of project management is to switch to simply releasing often and frequently managing the pace at which a team releases new things and improves their software and prioritizing the next things to do correctly. We do a weekly all hands meeting where we take a few minutes to call out new/improved things. It's a very positive meeting where we celebrate progress. The flip side is that it's very visible if you have nothing to show. So, it creates a pressure to show something meaningful. The rest is just normal planning. I set the goals for the team on a month by month basis and drive things forward. This in turn is done based on a roadmap that we revise every quarter. We identify themes where we want to do better. If I set the bar too high, I simply end up with a pile of unfinished things that spill over into the next month. You actually need to keep the queue of changes small and create space for people to do the job properly. Piling on more stuff actually reduces the likelihood of anything getting done or done properly. We're a startup and we release often so there's no question about there being something to release because there always is a usable version of the software. Our sales people have been instructed to sell what we have, not what they'd like us to have. That just creates pressure to deliver random crap that they thought the customer wanted to hear. Usually exactly the wrong thing to begin with. We talk only about things we already finished and know we can deliver externally. If you run a startup, stop talking about what you are going to have and start talking about what you already have does wonders for your credibility and sales. Unless what you have is nothing of course. In that case you fake it until you make it (or fail). And there's also very little doubt about what it is we're releasing. It's literally what we showed last week + some small changes that we can do this week. People get motivated by noticeable progress. Makes them want to do more of it. It's great to see this working. Our velocity is crazy good.
doix 4y ago
I believe the author has only worked at a certain type of company where his points might be true. But if you work at a place where software supports the main business rather than being the main business, I personally found that they were not true. At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped). Before a project is even started, time is spent doing a "feasibility study". The hardest problems are usually solved then (in isolation), tech stacks are evaluated and chosen, any hard algorithms are written and bench-marked to see if they scale, etc. The deadline is padded to hell to allow room for stuff to slip and scope is clearly defined. If/when development starts to slip, stuff gets de/re-scoped pretty quickly to make sure things do hit the deadline. The deadline was pretty much never arbitrary, it would depend on when a different project(not software) would start/finish so that the next one could use it. If all hell broke loose and the deadline was somehow too optimistic, then the deadline would move to the next time it was a good time to launch the software, not just a few weeks (since no one cares at that point). A specific example, we made a tool to analyze production test data for semiconductor devices. tl;dr a few thousand devices per wafer, _many_ production wafers, _many_ tests per device, basically "big data" (trillions of rows). We spent a few months evaluating different databases/schemas until we found one that worked. We knew pretty much all the queries that people would want to run against the data and made sure they would be fast. The tool was meant to replace a vendor tool we paid for. The deadline was for when the contract was meant to renew. If we missed the deadline, the deadline would have moved to the next year (next contract renewal). This wasn't a software company, a lot of processes were pretty messed up, but the stuff the author complains about was pretty good. Probably because it was a semiconductor engineering company that always hit deadlines to get stuff to the fabs on time. The downside is of course is that you are a "cost-center", not great for career development.
- laserlight 4y ago
  > At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped) I call those “deadlines” time boxes. I believe that the industry would greatly benefit from distinguishing the two.
  - 4y ago
deleted 4y ago
[deleted]
surfingdino 4y ago
If you have ever worked on project subject to regulatory deadlines or on a project that involves manufacturing you'll know that deadlines are a real thing.
d1sxeyes 4y ago
> You can’t simply start training today and run a half marathon tomorrow, for example. Particularly bad example - most organised half-marathons occur on a specific date, which means that there is a deadline for the training. What the author is actually saying is 'unachievable deadlines are pointless', which I largely agree with.
golf_mike 4y ago
"Which team would you rather have in your organization? I’d definitely prefer the first" The first team that was introduced was the erratic one, did you mean the second?
29athrowaway 4y ago
When you are busy thinking about the short-term, you are not thinking about the long-term: - career growth - compensation, bonuses And that is by design. Keeping people always in a rush is a way to distract them from their growth aspirations.
commandlinefan 4y ago
This is basically what the agile manifesto said before everybody who started doing "Agile" started ignoring it.
JohnFen 4y ago
The point of deadlines isn't to improve developer performance at all, though. The point is to allow planning for all of the non-dev parts of releasing software: marketing, etc. Deadlines aren't inherently evil. They're necessary. Abusing deadlines by setting them unrealistically, or by using them to try to goose production speed, is evil.
- deleted 4y ago
  [deleted]
pards 4y ago
There are a few small but critical errors in the article. > Imagine you have two sales teams. One produces unreproducible and unpredictable revenue spikes, while the other generates consistent and continuously improving results. [...] Which team would you rather have in your organization? I’d definitely prefer the first I think he means the second. The labels of the X and Y axes on the graphs for the coin tosses are transposed. It's not possible to have a negative number of coin tosses. At the start, he also mentions training for a half marathon but then running a marathon later (not a half).
v0idzer0 4y ago
Really enjoyed this piece, but… > Instead, we must ensure the system is always processing the shortest, most valuable items. Typically the most valuable items are always the longest leaving this criteria impossible to evaluate. Do you do the most valuable? Or the shortest?

186 points by lucasfcosta 4y ago

TLDR >> Preemption points are regular time intervals at which the team will review a task’s progress and decide whether they should cut scope, change their strategy, or drop the task and cut losses altogether.

layer8 4y ago
That definition is too abstract for me. If there is no deadline, why would one cut scope or drop the task? Conversely, why do I need preemption points to decide to cut scope, change strategy or drop the task? Usually the realization/decision comes naturally during implementation, without needing artificial occasions at constant intervals.

hknmtt 4y ago

In my last two jobs I refused to have deadlines. It's done when it's done and there is no one that can do anything about it. Companies need to accept this.

hinkley 4y ago
There’s some value in giving constraints to junior developers. There’s some value in getting senior devs to look at the calendar and re evaluate their plans. Estimates can trigger both of these, but they trigger bad consequences as well. Personally I’ve found that an engaged boss who I respect and occasionally points out I’ve sure been working on X for a while, is everything okay? To be at least as helpful as schedules. But if I could figure out how to get that consistently, I’d be on a book tour instead of keeping an eye on some people doing a deployment while I should be in bed.
- Akronymus 4y ago
  I am somewhat of a junior dev. Without deadlines I have a LOT of trouble keeping on task.
  - astura 4y ago
    This is really common and I expect it from my Jr devs and plan accordingly. So don't feel bad for it (not that you said you did).
    - hinkley 4y ago
      What we never ever learn is that never doing something is not an antidote for doing it all the time. It’s just exchanging one stupid extreme for another. My suspicion is that it has something to do with learning the wrong lessons from Boolean logic. The principle of the excluded middle applies to bits, not process.
treeman79 4y ago
Senior developer will be able to offer a range of options. X in year. Y in a month. Z in a day. Etc. Maybe Z is good enough. Maybe only X is.
heurisko 4y ago
You would have been removed from the project I was working on, which was responding to a governmental regulatory deadline.

est 4y ago

I think deadlines are really tech debit & credit, it's useless in a technological sense but a driving force business-wise.

PragmaticPulp 4y ago

It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason. That might be moderately true for, say, someone developing a new app feature that gets shipped to users who aren’t expecting it. However, it’s not true at all when the software development output is a gating feature for real-world contractual obligations and other such business drivers. In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain. This doesn’t guarantee that a target date will be hit, of course, but it’s not impossible to produce estimates that are reasonable accurate a large percentage of the time. Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible. I suspect many of the developers who believe that target dates are always arbitrary, pointless, and impossible to estimate have mostly worked in big cash-rich environments where it didn’t really matter when a feature shipped. If you go to the other end of the spectrum and talk to engineers who work in industries where target dates are critical you’ll discover a lot of people who are very good at breaking down projects and accurately estimating dates without relying on crunch time to get things done. It may sound impossible if you’ve never worked in an industry that requires such precision, but it makes sense after you’ve worked in such an environment for a while.

bagels 4y ago
When your software is a piece of a much larger, expensive real-world project, deadlines are not pointless. Imagine, for instance, writing software for an interplanetary probe with a short launch window. Pretty different from writing the 'Yo' app.
arnvald 4y ago
Most deadlines in my career so far were arbitrary. Sure, some deadlines were driven by fixed events, for example Christmas promotion has to be launched before Christmas. But in most cases when I asked managers about the reason behind the deadline, the answer was something like "oh,I promised this team/director we'll do it by then". When I dug deeper to see what happens if we miss the deadline, it appeared the said team would be just fine, there were no real life consequences, just that they wanted to finish their part of work by certain time, and they depended on us. I'm not saying deadlines are useless, but they're very often driven by some arbitrary promises made by managers before even consulting developers about the complexity of work to be done.

650REDHAIR 4y ago

Without a deadline I do not function well.

and-not-drew 4y ago
Parkinson's Law - "work expands so as to fill the time available for its completion." https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
- mellavora 4y ago
  Yes. Which is why it is nice to have deadlines. As several people have mentioned above, it limits scope.

aspyct 4y ago

I would rather have deadlines than give estimates. A deadline is a clear moment in time when the feature is needed. There's a reason behind it. "We need to be ready for event X", "Next billing period is in a week". Fixed deadlines allow you to negotiate the content of the feature, and make meaningful choices when it comes to the amount of details and edge cases to handle. Otherwise how are you supposed to estimate something? I can make you the same feature in a week or in a month. It's going to be more polished in a month, of course, but I can squeeze it in a week if needed, with limitations. Embrace deadlines, you will love them.

miriam_catira 4y ago
This. Fixed deadlines based on real, immutable events. My current role had flexible deadlines. It makes me crazy. All that allows for as unchecked scope creep. So I can't estimate, because the teams requesting the work refuse to define a project's final state (or are incapable?) and it's often impossible to make arbitrary deadlines because they're not real either. I get almost nothing shipped. And when I do, it's literally $7k over or $6k under!
UK-AL 4y ago
Real hard deadlines aren't that common in real life except in a subset of industries. What people want estimates for is budget reasons. They want to lock down both scope and time. So if you want to start removing edge cases and details you'll often find they don't want to do that either.
- aspyct 4y ago
  Most of my work, in two very different lines of work, is bound to strict hard deadlines. As I mentioned, those are events, reports to external entities, billing etc... I'd say 75% of my dev work is hard deadlines.
commandlinefan 4y ago
> I would rather have deadlines than give estimates Well, in reality, estimates are deadlines that they want you to feel like you came up with in the first place. You don't have to play that game very many times before you realize that they ask for an estimate, then try to argue the estimate down to whatever they had actually budgeted in the first place - but make it seem like it was your commitment in the first place.

proc0 4y ago

Deadline or not, I think you still want a prediction of when something lands for many reasons. In my experience most deadlines are set based on initial estimates (which often include technical feedback), but then those estimates get locked in because of advertising/marketing and setting customer expectations. In my opinion the biggest problem is not understanding that estimates are constantly changing based on continuous change of information as the project is worked on. Also, I've rarely been in a team that takes the time to define a unit of work, which is relative to the stream of work that is done. Breaking things down into work units allows consistent measurement relative to who works on it, and then allows for pretty accurate relative estimates, which is good enough to predict completion dates. I suspect this is harder to manage, but if done right, predicting the completion date accurately (despite any deadline) is a necessary step to then speed up that process.

commandlinefan 4y ago
> you still want a prediction of when something lands That's the problem. Of course you want that. Everybody would want that. Our lives would be easier if we always knew exactly when something would be finished and how much it would cost. What you don't seem to recognize is that if predictions could be made with that kind of accuracy... you could be replaced with a spreadsheet. The only reason you're still around is because our work is inherently unpredictable.
- proc0 4y ago
  Right, but eventually you have to lock it in, or there would be no point in announcing a release date or letting your customers know when to expect it. While I like the idea of never worrying about any kind of completion date, I would think it's better for business to set customer expectations. Of course it backfires if you don't hit that date, but not having one could also backfire if when the project is done no one cares to use it anymore. For me it starts with predicting accurately units of work, regardless of desired completion date. Then work with that to speed things up if needed, and use that information for estimation.

awb 4y ago

Semi-related recent This American Life Podcast about deadlines: https://www.thisamericanlife.org/776/i-work-better-on-deadline https://www.thisamericanlife.org/776/i-work-better-on-deadli...

lisper 4y ago

I like deadlines because they help me decide how to prioritize my time. I think the problem with deadlines is not the deadlines per se but how people think about them. I think most people think of a deadline as a time by which something needs to be done or something horrible will happen. I think of a deadline as a time by which if I get it done something good will happen (my customer will be happy). It amounts to the same thing, but focusing on the kudos I'll get if it's done on time vs the (usually imagined) catastrophe if I don't makes a world of difference.

boffinism 4y ago

This whole article feels like it was written by someone who never really stopped to understand what deadlines are or why they exist. The author was only concerned with how they impact them, and desperate to push back. For one thing: "In a system that awards bonuses to those who reach a $50,000 deadline..." Not a deadline.

beckingz 4y ago
$50k by end of month is a sales goal with a deadline?

Test0129 4y ago

Absolutely anything is better than sprint pointing. This garbage process was adopted from what I can only assume is some cabal of "agile consultants". I have over 10 years in the industry. I cannot estimate something with less than a 20% margin. An estimate requires you to know everything up front, at that moment, for it to be accurate. Anyone who has made software knows this is never the case. The only thing it allows, and what I can assume is the only reason it continues, is because it's a job creation program for "agile certified" project managers and it produces a nice burn down/up chart you can show the manager. Sure, you can call points deadlines, but they are not. It's an arbitrary measurement of a unit of work that in total makes up a two week "deadline". Two weeks isn't enough to produce good code on anything more complicated than a boilerplate application. Deadlines are far better. Tell me something needs to be done by next month it will be done. I can negotiate inside these bounds to prevent scope creep because a deadline is far more flexible than points. If you find yourself done with deadline work, you can refine and add touch ups. If you find yourself done with pointed work the PM will just assign you more work to "keep your points up" instead of allowing you to do the same. The tyranny of the agile PM hinges on convoluted point systems. Even the one the writer prescribes. Force the management to actually agree on a deadline that is reasonable (not ship me facebook next week) and watch how productive and accurate developers can actually be. Read the comments here. Agile has been butchered to the point it's unrecognizable. Give me deadlines.

AussieWog93 4y ago
100% this. No matter how arbitrary and irrational deadlines might seem, they at least work somewhat well.
FrankyHollywood 4y ago
exactly my experience, a reasonable deadline defines the design and scoping, and makes you give right expectations to a customer. I left 2 jobs because of rigid scrum, couldn't handle the insane discussions. "how many complexity points do you estimate?" "euh, what was our velocity?" "no, you can't think in hours, give me complexity POINTS!" "I dunno, probably 2 to 3 weeks of work, to many unknowns" "unknowns? we refined this story, there are no unknowns!" "ok, 3 weeks = x points" "no, you can't say 3 weeks, we have 2 week sprints. You should split the story in 2, where each story is a well defined functional component which we can show in next demo".... "but, it is 1 thing, you can't split and have it working for next demo..." mind torture... so I left Nowadays I have a very experienced team. We do daily standups (without a scrumboard, just real conversation), we define deadlines, can be a week, can be 2 months. Demo's only when needed, kind of the way I used to work before rise of scrum :)

tsimionescu 4y ago

This article seems based on the flimsiest logic, or on experience in extremely dysfunctional organizations. > When teams miss a deadline, it’s too late to take any productive actions. > Think about the actions you can take once your team misses a deadline: > 1. Set a new deadline > 2. Fire someone > 3. Cut scope Obviously, if you only discover that you missed the deadline on the day it passes, you can't do anything productive about it. But no one (competent) works like that: you adjust your work and your scope based on the deadline for the entire duration of the project. Starting from basic design ("we need to ship this feature in 2 weeks" will lead to a different design than "we need to ship this feature in 3 months") to design/scope adjustments ("we've been working for one week and we can see this is not going to finish in one more week, do you want us to adjust the scope/design, or is it preferable to push the date further out?"). I suspect a root cause of this problem is the following idea, from the "Queueing disciplines section": > We can model every software development process as a queueing system. In such a system, tasks come in on one end, and software comes out on the other. This is a fundamental misunderstanding of how software development works, at least for the vast majority of cases. Tasks are not an input of the software development process, feature requests are. Tasks are an intermediate output - you have to put in work to refine vague feature requests into concrete tasks. The same feature request can be translated into many different tasks, depending on various factors (competition, expected timeline, team experience, external dependencies etc.). For a concrete example, say the team is working on building an alternative to Wireshark (a packet capture and analysis tool). A PM may ask the team to add support for QUIC to the product. In the ideal case, the tool would be able to understand every kind of QUIC packet, partially recognize some of the more common malformed packets, support decryption of the contents via one or more popular key logging formats etc. But, depending on product architecture, this may take half a year to fully implement. If the PM desires some minimal support for QUIC in, say, 2 months (perhaps to coincide with some fiscal quarter), then they need to work with the team today to find a meaningful subset of features that can be implemented and delivered in ~2 months. Of course, during those two months, the team may discover that they are working faster or slower than anticipated, and may need to adjust the scope even more. Even so, the deadline may still be missed of course (say, one of the lead developers falls ill two weeks before the deadline, or a fundamental misunderstanding of the protocol that was causing sporadic bugs is understood only 1 week before). However, if the PM only added a "support QUIC" "task" to the team's queue, with high priority, the team will almost certainly have nothing even close to releasable 2 months after the request was added, even if they are working at the exact same pace - since they focused on a more advanced version of the feature. Even if they are internally working in a way where they avoid having non-releasable features for such a long time, they are very likely to have prioritized other aspects of the feature than what the PM needed, and have only finished and polished those by the (unknown to them) 2 month "deadline".

mikessoft_gmail 4y ago

good and usefull article

nottorp 4y ago

Again Joel had something insightful years ago. https://www.joelonsoftware.com/2006/08/10/the-identity-management-method/ https://www.joelonsoftware.com/2006/08/10/the-identity-manag... He was sort of leaning towards April 2007; I was sort of leaning towards December 2006. [snip] What I explained to Brett, though, is that we want to hire six new people in the spring, and the chances that we’ll be able to afford them without FogBugz 6.0 are much smaller. There are deadlines and deadlines.

smallstepforman 4y ago

In the embedded world, there are hardware teams, software teams, externel suppliers, contractors, marketing, trade shows, etc. Deadlines are a real thing, and dozens of teams are effected. If you cannot schedule and execute properly, you are out of your league. As a professional engineer, I stand and stake my reputation on meeting agreed deadlines. Otherwise, it’s a sign of amatuer work or even worse, unprofessionalism. I’m cursed/blessed with an Engineering mindset, and expect the same from my peers.

mobiuscog 4y ago
I suspect you also have detailed specifications and requirements to allow estimation and planning. Outside of hardware-based environments, this is often missing and engineers that push for it are dropped because they are not 'autonomous' enough.

Joel_Mckay 4y ago

In general, constraining the estimated time to completion can telegraph redundancy is necessitated in a complex project. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_... Or from another perspective, the probability a given team can successfully finish a key project deliverable diminishes after a projected time. If the hard parts of a problem still remain, the progress has in fact stopped when resources start being diverted to non-critical tasks. The statistics indicate if a person says they are 95% certain, they are in fact 60% certain, and unaware of their bias. Good luck convincing the Dev-ops crowd though... being busy means progress to some folks. ;)

unfamiliar 4y ago

> A system will produce what it can produce, regardless of whether you set a goal. This is just fundamentally not true for human beings. Certainly not for all of them; I know personally I need a bit of time pressure to perform my best.

taubek 4y ago

If you are building a software (or anything else for that matter) for a specific event that has a starting date carved in stone then you can't avoid deadlines. Take some sporting event for example. Let's say F1 competition. You must have racing car ready by the start of the season. Having it ready two weeks latter is not an option.

satisfice 4y ago

I use deadlines as a heuristic. Without them I have a hard time focusing my work at all. That doesn’t mean I let myself be abused by arbitrary deadlines. Deadlines are useful to me, however I have always advocated the use of periodic check-ins to give us a chance to adjust our course. It’s weird when people make claims that are so easily shown to be wrong, as this author does, except some of that might be him using “deadline” to mean something less heuristic and more draconian than I do. I published a regular feature in IEEE Computer magazine for 12 months. I never missed a deadline. But the way I did it was by using a series of fake deadlines (up to three). I asked the editor not to tell me what the real deadlines were. I missed at most two of the fake deadlines during that year. The system worked well for me because I don’t like to stop daydreaming until the last minute. Daydreaming and playing are divergent activities that generate value; but convergent activities are needed to actually deliver.

6stringmerc 4y ago

Either you make peace with deadlines, or get your ass out of the kitchen. Seriously. I work in proposals and deadlines are not negotiable - well, unless the solicitor changes the deadline, but it’s up to them. Whining about the pressure that comes with deadlines is pathetic to me, because I make my living whipping people into shape to deliver on time. I have all the accountability and none of the authority in my role - sound familiar to software engineers? The difference is that my deadline work is people management and software is working with a machine that does what you tell it to do. People don’t do what you tell them to do, at least not consistently. They try, but unless it’s a priority, it’s hit or miss. The reality is you have deadlines because your customers have deadlines and problems they need solved. If your sales team and executive leadership consistently puts you in positions where it’s difficult to succeed at what you are capable of doing, start your exit plan. Just because shit managers push their terrible deals downward doesn’t mean the system is at fault. Deadlines are healthy to keep progress and be able to move on to another new challenge. Besides, we humans are on a deadline to get all our living done. It’s as ingrained as yelling at clouds or tilting at windmills. Get busy livin’ or get busy dyin’

Tainnor 4y ago
I have never yet seen a software team, team lead, engineering manager, etc. that knew how to estimate accurately how much time a large software project will take. I have repeatedly seen people saying things like "the rewrite will only take a year", "we'll have this done in two months", etc. which turned out to be wrong by orders of magnitude. I really think that, unless we're doing very repetitive stuff, the best we can do is give rough estimates on small deliverables, i.e. stories in a sprint. If what you write is true - deadlines are important - and what I write is true - it's almost impossible to estimate how long it takes to develop complex software - then there's a mismatch that needs to be addressed somehow. I thought that this was what Scrum was designed to solve (by continuously updating estimates), but you seem to think that we need harder deadlines. If so, I'm not convinced that this is actually feasible in most cases.
maeln 4y ago
> The reality is you have deadlines because your customers have deadlines and problems they need solved. And this is actually part of the issue (and in part what the article mention). Most project, including the one of the clients don't need deadlines. I never saw a project where the deadline was not arbitrary or govern by another project deadline who was also arbitrary. I also worked in many different context, some with hard deadline, some with 0 deadline. Almost all the time, the project with hard deadline stem from the fact that the management didn't trust their engineer. They taught that without this "pressure" we would just sit on our asses and not do anything. While I certainly encounter co-worker who would gladly not do a thing and be paid, almost every engineer I worked with was happy to work and took some pride in his job. The no deadline / soft deadline project usually faired much better with a much more happy team and client. First off there was a mutual trust between management and the team "on the ground". They trusted us to do our job and we trusted them to steer the project direction and give priority. This made the job just that much more satisfying. Secondly, there was almost never a period of rush / crunch. It could happen that we had to rush a feature, but it was infrequent, short lived, and never to the extent of putting an all nighter. This means that the team had a very consistent and predictable productivity, we didn't have any burnout and people where not likely to leave in the middle of the project, so we were never short staffed out of nowhere.

bambax 4y ago

Funny that the article doesn't even reference the most famous quote by Duke Ellington: "I don't need time. What I need is a deadline." Sure, deadlines add "pressure". But we can't wait forever for something to exist. A feature needs to be shipped at some point.

jillesvangurp 4y ago

Always reminds me of the famous Douglas Adams quote: “I love deadlines. I love the whooshing noise they make as they go by.” In seriousness, the author is right. Deadlines don't work as a tool to coerce people to work faster/better. Unless you have a detailed plan to get there; in which case the deadline is less important. It's just the last step of the plan. You'll know long before the deadline whether you are on track. Scrambling a few days before the deadline when you realize you are definitely not going to make it is probably doing more damage than good. And there's only so much that you can pull off in a few days. Doing that means you've already failed and you are just trying to cover it up. A useful tool to get out of a deadline driven / firefighting style of project management is to switch to simply releasing often and frequently managing the pace at which a team releases new things and improves their software and prioritizing the next things to do correctly. We do a weekly all hands meeting where we take a few minutes to call out new/improved things. It's a very positive meeting where we celebrate progress. The flip side is that it's very visible if you have nothing to show. So, it creates a pressure to show something meaningful. The rest is just normal planning. I set the goals for the team on a month by month basis and drive things forward. This in turn is done based on a roadmap that we revise every quarter. We identify themes where we want to do better. If I set the bar too high, I simply end up with a pile of unfinished things that spill over into the next month. You actually need to keep the queue of changes small and create space for people to do the job properly. Piling on more stuff actually reduces the likelihood of anything getting done or done properly. We're a startup and we release often so there's no question about there being something to release because there always is a usable version of the software. Our sales people have been instructed to sell what we have, not what they'd like us to have. That just creates pressure to deliver random crap that they thought the customer wanted to hear. Usually exactly the wrong thing to begin with. We talk only about things we already finished and know we can deliver externally. If you run a startup, stop talking about what you are going to have and start talking about what you already have does wonders for your credibility and sales. Unless what you have is nothing of course. In that case you fake it until you make it (or fail). And there's also very little doubt about what it is we're releasing. It's literally what we showed last week + some small changes that we can do this week. People get motivated by noticeable progress. Makes them want to do more of it. It's great to see this working. Our velocity is crazy good.

doix 4y ago

I believe the author has only worked at a certain type of company where his points might be true. But if you work at a place where software supports the main business rather than being the main business, I personally found that they were not true. At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped). Before a project is even started, time is spent doing a "feasibility study". The hardest problems are usually solved then (in isolation), tech stacks are evaluated and chosen, any hard algorithms are written and bench-marked to see if they scale, etc. The deadline is padded to hell to allow room for stuff to slip and scope is clearly defined. If/when development starts to slip, stuff gets de/re-scoped pretty quickly to make sure things do hit the deadline. The deadline was pretty much never arbitrary, it would depend on when a different project(not software) would start/finish so that the next one could use it. If all hell broke loose and the deadline was somehow too optimistic, then the deadline would move to the next time it was a good time to launch the software, not just a few weeks (since no one cares at that point). A specific example, we made a tool to analyze production test data for semiconductor devices. tl;dr a few thousand devices per wafer, _many_ production wafers, _many_ tests per device, basically "big data" (trillions of rows). We spent a few months evaluating different databases/schemas until we found one that worked. We knew pretty much all the queries that people would want to run against the data and made sure they would be fast. The tool was meant to replace a vendor tool we paid for. The deadline was for when the contract was meant to renew. If we missed the deadline, the deadline would have moved to the next year (next contract renewal). This wasn't a software company, a lot of processes were pretty messed up, but the stuff the author complains about was pretty good. Probably because it was a semiconductor engineering company that always hit deadlines to get stuff to the fabs on time. The downside is of course is that you are a "cost-center", not great for career development.

laserlight 4y ago
> At my previous gig we always had deadlines and we never missed them (technically, stuff gets de-scoped) I call those “deadlines” time boxes. I believe that the industry would greatly benefit from distinguishing the two.
- 4y ago

deleted 4y ago

[deleted]

surfingdino 4y ago

If you have ever worked on project subject to regulatory deadlines or on a project that involves manufacturing you'll know that deadlines are a real thing.

d1sxeyes 4y ago

> You can’t simply start training today and run a half marathon tomorrow, for example. Particularly bad example - most organised half-marathons occur on a specific date, which means that there is a deadline for the training. What the author is actually saying is 'unachievable deadlines are pointless', which I largely agree with.

golf_mike 4y ago

"Which team would you rather have in your organization? I’d definitely prefer the first" The first team that was introduced was the erratic one, did you mean the second?

29athrowaway 4y ago

When you are busy thinking about the short-term, you are not thinking about the long-term: - career growth - compensation, bonuses And that is by design. Keeping people always in a rush is a way to distract them from their growth aspirations.

commandlinefan 4y ago

This is basically what the agile manifesto said before everybody who started doing "Agile" started ignoring it.

JohnFen 4y ago

The point of deadlines isn't to improve developer performance at all, though. The point is to allow planning for all of the non-dev parts of releasing software: marketing, etc. Deadlines aren't inherently evil. They're necessary. Abusing deadlines by setting them unrealistically, or by using them to try to goose production speed, is evil.

deleted 4y ago
[deleted]

pards 4y ago

There are a few small but critical errors in the article. > Imagine you have two sales teams. One produces unreproducible and unpredictable revenue spikes, while the other generates consistent and continuously improving results. [...] Which team would you rather have in your organization? I’d definitely prefer the first I think he means the second. The labels of the X and Y axes on the graphs for the coin tosses are transposed. It's not possible to have a negative number of coin tosses. At the start, he also mentions training for a half marathon but then running a marathon later (not a half).

v0idzer0 4y ago

Really enjoyed this piece, but… > Instead, we must ensure the system is always processing the shortest, most valuable items. Typically the most valuable items are always the longest leaving this criteria impossible to evaluate. Do you do the most valuable? Or the shortest?