10 ms·

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

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.
- ahaproudowl 4y ago
  Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!" Proper safety checks wouldn't let the plane leave the ground. Delays in that critical state are inconvenient, but you accept them because the alternative is not acceptable. We should treat software in exactly the same way, It's ready when it's ready. The issue is the illusion of control. A bad CEO will measure the performance of his CTO by productivity alone. A good CEO will measure the CTO's output by consistently increasing quality.
  - hef19898 4y ago
    >> Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!" But that is how it is done??
    - ahaproudowl 4y ago
      The delivery date of an airplane and it's flight schedule are two completely different things. The delivery date is an estimate and the date can shift until the plane is safe to fly. The deadline for delivery is not a true deadline and the factory will only work to its safe production limit to deliver the plane. A bad practice would be to just put the plane out on the tarmac, regardless of state. It works to the safe productivity limit of the factory, not the arbitrary demand of the customer.
      - hef19898 4y ago
        Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont. And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of?
        lmm 4y ago
        > Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont. Both Boeing and Airbus have missed a bunch of delivery dates this year and will continue to do so. For some of them they're blaming regulatory approval. Guess what, it happens, life goes on, people in that industry can at least recognise that it's better than flying a plane that hasn't been approved. > And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of? They do, and again the point is: what happens if the plane isn't ready? It doesn't fly until it is. They don't ignore the checks because they have a deadline.
senectus1 4y ago
funny given that only a month ago he was expounding the benefits of "Talk To Your Customers" [1] aka "Agile", which is essential artificially and programmatically governing your day via deadlines. [1] https://lucasfcosta.com/2022/08/03/talk-to-your-customers.html https://lucasfcosta.com/2022/08/03/talk-to-your-customers.ht...
- Apocryphon 4y ago
  The TFA still talks about talking to one's customers, so this doesn't really contradict it. > If your team can’t ship without deadlines, the lack of deadlines is not the problem. Your team’s careless attitude about customer feedback is. > When teams obsess about customer feedback, they ship as early as possible so that they can listen to their customers. > For customer-centric teams, artificial deadlines are useless because the only “deadline” that matters already exists: “as soon as possible, as long as it’s valuable.” You're choosing to conflate listening to customer feedback with Agile.
  - antupis 4y ago
    Yup this you ship as fast and often as possible and then listen customer feedback. Deadlines traditional sense are working against you here because what they imply is some-kinda fixed set of features what are delivered to certain date.
  - senectus1 4y ago
    >You're choosing to conflate listening to customer feedback with Agile HE draws that link... >In this post, I’ll present a robust and disruptive Agile framework. It’s called “talk to your customers” — or, in short, TTYC.
0x20cowboy 4y ago
It’s not that deadlines don’t exist (for some business reason), it’s just that trying to have both a deadline and a set of completed features is contradictory (if you want something that works well). You can set out to have a set of features, and you can have a deadline, but thinking all the features will be completed (and completed well), on that day has never worked (in my experience). You just wind up with rush hacked garbage towards the end. This is what I’ve done successfully for years now (when I am not forced by a PM to do agile): https://concentric.works/ https://concentric.works/
- methyl 4y ago
  That was a good read, thanks. Similar in principles to ShapeUp, which I think is one of possible implementations of Concentric. I like that it's defined loosely and you can use it as a basis for process that will fit your team.
- UK-AL 4y ago
  This is what agile actually wants you to do. You can have a deadline but no fixed scope, this what CI/CD is for. So when deadline day happens what you have is already released. Or you can have fixed scope but no deadline. Or you can have fixed scope & deadline, then pad things to hedge risks that might pop out. Agile prefers the first.
  - Frost1x 4y ago
    >This is what agile actually wants you to do. And almost never does because it's designed in a way that's easy to abuse. Instead you often see dynamic ever-changing scope, dynamic ever tightening deadlines, and no margins for risk. Everything is on fire always and you just chase the fires around with your dev teams to put out fires, crack whips, and ask why features are behind schedule. It's madness in much of the industry.
  - 0x20cowboy 4y ago
    > This is what agile actually wants you to do. Maybe, but I am not sure, and that’s not the way I’ve ever seen it done. The only way I’ve ever seen agile done is “waterfall with two week sprints”. Large wireframes of an entire application which is “unreleasable” until the end. Sure it compiles during each sprint, but it’s not a releasable product at any stage (until the mad rush at the end when all the negotiations and trade offs begin)
afarrell 4y ago
One cause of this is that we as a community have not properly shouldered the responsibility to teach good estimation skills to new engineers. It is a skill I likely now need to be able to teach —- though I still need to learn it myself.
KronisLV 4y ago
> 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. I am yet to see this done well, though hearing that it's apparently possibly has me cautiously optimistic. In my experience so far, however, I've mostly seen incomplete requirements (one could argue that a perfectly accurate spec would be no different from executable code, the end product itself), changing requirements, difficulties in estimating the impact of needing to migrate old data or accommodate/refactor old logic, little proper estimation of testing overhead, the impossibility to predict how long working with external services and integrating with them would take, especially when cross coordination with another team is necessary, the impossibility to predict what might break in regression testing or additional edge cases that might be discovered, as well as the greater impact of needing to utilize particular tech stacks (e.g. Kubernetes with a particular service mesh) due to external requirements. It's gotten to the point where I feel like adding a new form to any given application might take anywhere from 2 hours to 2 weeks, depending on what's going on in it (e.g. a well architected and simple monolith with onboarding guides and commented code vs microservices with little to no documentation, to serve as examples of different orders of magnitude of complexity). Estimations feel like just making stuff up on the go at best and like something actively harmful (being urged to make promises that are going to be false a lot of the time) at worst. The only way to do them would be not to do them - instead have some software look at the issue request and say: "Okay, you have X requirements of the following type: ..., after analyzing this project's issue history and time tracking across 5432 issues, it would appear that this issue would take between 4.2 and 7.3 days to resolve." To me it seems that if you need to be able to give accurate estimations, you'd also need a very predictable and boring tech stack across many if not all of your projects, which doesn't seem feasible in web dev, given how fast everything seems to progress and given how much CV padding one must do to remain hireable (instead of, say, using jQuery in 2022).
Existenceblinks 4y ago
I'm a type of person that can't live without deadline. If my mom doesn't say "today" in her order, I'd forget to do it.
Zanfa 4y ago
> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible. Judging by the constant stream of overdue and overbudget projects in more traditional businesses like construction, which are significantly stricter in terms of regulation, planning and have been around forever compared to software engineering, I'm not convinced accurate deadlines are possible.
- 6stringmerc 4y ago
  Depends on the nature of the work - I recently did a gig at a civil design engineering firm and multiple projects came in at or under budget and on deadline. We’re there some serious overtime crunch periods on a couple of them? Yes, but for a multimillion dollar project with expiring Federal funds, it was achieved as set forth. I think we tend to hear more about the failures than the successes - the Omni hotels in Houston and Dallas built with bond funds were repaid years earlier than mandated because they were successful, for instance.
  - Cederfjard 4y ago
    Estimates aren’t necessarily accurate just because they end up being close to reality - that could just be chance. The estimate for a project that came in substantially under budget was just as wrong as one that came in substantially over, it’s just easier to live with. If all estimates are wild-ass guesses, then some will come in on time and budget, some will undershoot and some will overshoot. I do believe that estimates, even for complex projects, are useful and can be fairly accurate, and in a lot of circumstances they can be used as the basis for deadlines, with certain considerations.
    - Frost1x 4y ago
      If "achieving" your estimate included a lot of crunch, your estimate was bad. A lot of poor estimation externalizes it's error to those trying to meet the estimate. Long hours, weekends, etc. over months while pretending the work fit on a nice paced 40 hour week with breaks is not a good estimate. Chances are, there's probably a lot of corner cutting in the final product as well, because your requirement set and associated deadline was the priority vs having a quality product delivered.
croo 4y ago
I am one of these developers. Let me give you an example of a real life consequences deadline where the project is state financed with money provided by EU, the end of the current political party term is nearing and the money is available on the premise that the project is finished successfully. "Is done" is actually approved by a third party inspector who not necceseraly works in your or the project's best interest. The project done by several separate subcontractors and if fails the political party looses faces before elections and if it fails to deliver the money provided by EU won't ever arrive and you won't get a dime. But you will pay the consequences of a failed contract. I was an IT pm/ba/architect for one of the subcontractors. This project gave third of our annual income. Should we miss it it has the chance to bankrupt the company and as a bonus you have an angry political party against you. Go, plan it, estimate it, deliver it on time. I agree that every deadline is artifical and negotiable but EU financial support deadline is a fuckin hard deadline because you cannot possibly have the necessary network and position to initiate any kind of change.
jnsaff2 4y ago
I think what you say and he says are not that different: he argues that the concept of deadlines is really pressure which is also what being not cash-rich is about, you have limited resources, therefore you have pressure to make the most out of them. So deadlines can be a lazy, dumb or crude way of pressure and may not have the intended effect. Surfacing the real reasons and dealing with them directly might be more effective.
praptak 4y ago
"then the software development output is a gating feature for real-world contractual obligations" Cool, I hope that whoever agreed to these obligations knew full well that they were taking a gamble and are prepared to deal with the consequences of the gamble not playing out. A complex software project is already a gamble. It may drag on for years even after the most pessimistic time estimate. it may totally fail (the outcome which is rarely taken into account). Drawing an arbitrary deadline on top of it just makes it a more risky gamble.
gadders 4y ago
It shows they have never worked in a regulated industry like banking. FRTB, MIFID 2, PRIIPS RTS etc etc all have/had fixed deadlines and sanctions against the company for non-compliance.
- hef19898 4y ago
  Or heard the term "monthly / quarterly / year end closure in places they worked at. Or faced contractual penalties for late deliveries. Or faced some deadlines caused by investors / burn rate, or any number of reasons. Or, the other way round, had to wait for someone to finish things they needed or wanted, e.g. a plumber showing up at their place to repair a leak. People refusing to commit and see those commitments through are such a pain to work with.
  - gadders 4y ago
    Agreed. It's a naive view.
Singletoned 4y ago
Even his first metaphor falls down: > You can’t simply start training today and run a half marathon tomorrow, for example. You can, however, create a system in which you consistently increase the number of miles you run. The marathon will be on a specific day, ie a deadline. If you haven't finished your training before the day of the marathon, you fail.
- laserlight 4y ago
  Can you elaborate? I couldn't understand how the metaphor fell down. How does the existence of a deadline help me achieve it?
  - Singletoned 4y ago
    Creating "a system in which you consistently increase the number of miles you run" is pointless if it doesn't get you to the point where you can run the marathon on the day that it happens. How long you have until the marathon would determine what kind of training schedule (system) you create.
    - laserlight 4y ago
      > if it doesn't get you to the point where you can run the marathon on the day that it happens. Doesn't the same logic apply to the training system that we created based on time until the marathon? Does the existence of a deadline guarantee success of a training system? And, doesn't any training system increase the number of miles consistently? Because, if I am to run 26 miles, any training regime should make me able to run 5 before 10, 10 before 26.
    - jeltz 4y ago
      Yes and no. Having more time gives you more flexibility in how to plan it so you can for example either reduce injury risk or aim at running the race at a higher pace. But it is not like you can rush it beyond a certain level. I feel one of your misconceptions is that running a marathon (or a half as in the article) is something binary. A lot of people could just go out and run a half marathon tomorrow if they were forced to. The injury risk would be high and they would feel miserable, but they would make it. A full marathon requires much more training but all marathon training programs I have seen are overkill if the goal is just to complete the race. They are instead aimed at either making people complete it at a certain pace or complete the race while being able to enjoy it. If you have a lack of time to train you can sacrifice pace/enjoyment. Rushing the training on the other hand is stupid. So for marathon training the deadline is in the form of a hard cutoff where you have to decide if you are satisfied with that little training or if you want to wait until a later race. It is more like a release train which only happens a couple of times per year. Edit: Sorry for the rant, my real point is actually that you are encouraged to change your training plan on the fly to adapt to real life events and that while the race is a deadline it is very unclear what will be delivered at it until you get pretty close to it. Will it be a 3:30 marathon or a 3:15 one? Unless you have sponsors nobody will get angry at you for not delivering what you had planned to.
laserlight 4y ago
The fact that the deadline is not “arbitrary”, because it is a contractual obligation, doesn't automatically make the contractual obligation feasible. The reasoning behind signing the contract could still be based on “arbitrary” reasons, wishful thinking, political agenda, etc. Putting project constraints on paper doesn't mean that the project will meet those constraints.
- Frost1x 4y ago
  A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. It's especially common in larger businesses with layers of middle management that aren't held accountable and pass their poor decision making down, often making it difficult to identify the real problem they are to the organization. Even in small orgs, if you need to make unrealistic promises to compete, you shouldn't be competing and should refocus your business, your current business plan is flawed and its not inherently your employees fault that they can't deliver as efficiently against businesses that focus on some niche and have done so over decades or benefit from economies of scale and fat margins to pad such projects they can afford to operate at a loss.
  - nobody9999 4y ago
    >A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. There's an old saw that goes something like, "fast, cheap, good. Pick two." I've found that to be true over and over again. All three options can be useful depending on whatever it is that's being worked on. Many of the complaints in this discussion about setting deadlines seems to be that not enough resources are being allocated to meet the "fast and good" selection. Which, of course leads to an end result of "fast and cheap," which isn't the goal. The main argument seems to be that "cheap and good" is better than "fast and cheap" because there aren't enough resources allocated to achieve "fast and good." The solution, of course, isn't to eschew deadlines, but rather to determine the work required and make a decision about how the work should be done (with the above being a simple-minded way of describing that 'how'). It seems like deadlines become an issue when those setting such deadlines are focused on the "fast and cheap" pair, while the folks actually doing the work want "good" to be part of that pairing. As someone who has worked both in environments which focus on minimizing time and cost when bidding for work, and in those where estimates realistically reflect the time and cost of completing the work, I find the latter to be much more effective. The former is generally a shit show where no one is happy. The client either doesn't get what they need, or it's going to cost a whole bunch more than they were told, and those actually doing the work are pressed to work harder and faster because the client is pissed off. And the business generally loses in the medium to long term as well, as they're unlikely to get repeat business and certainly won't get referrals from that client. When good estimates are provided and the appropriate resources applied, projects often go much more smoothly and everyone wins -- over the short, medium and long term. Obviously this requires good planning and a strong understanding of the goals and requirements and translating those into reasonably accurate estimates. Those (as others on this thread pointed out) are skills that can be learned. Sadly, those skills seem to be in short supply. And more's the pity. Edit: Clarified my prose.
wruza 4y ago
Correct when true. But if talking about all deadlines, you can sort them by category. One that I especially don’t like are populistic deadlines, when team burnout is used to: impress or brag before someone, get some quick results only to spend few weeks before even looking into it, set out of a thin air in a project of an RnD nature. Deadline is not only a planning instrument, it is also a force that allows to tick the box regardless of a true state. You cannot always expect them to be used in a sensible way, because other departments and heads suck as much as you do, or more, if they are further from physical/informational reality. Tight budget means tight planning, but it might also mean that your chiefs are simply underperforming. Working on the edge of bankruptcy for years, never seen my “push hard this week (or: this sunday) it’s important to us” taken as important or used right away. I even learned to detect with high probability when the rush is based on cocaine and can be safely ignored. This is not a rebuttal (I agree that deadlines are useful), it’s just the back side of this shiny coin of “effective management”.
traceroute66 4y ago
> It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason. The one thing I hate more than that, is articles such as this one that waffle on for eternity using pseudo-science. For example, what do all the pretty graphs and paragraphs of waffle about coin tosses have to do with the price of eggs ? Its basically space padding that doesn't add anything to the argument they are trying to make.
koonsolo 4y ago
Your explanation sound reasonable, except for the fact that you seem to mix estimates and deadlines together. I don't trust the planning of anyone how doesn't make a big distinction between estimates and deadlines. So I would like to know how your development environment deals with this.
q-big 4y ago
> In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain. That is exactly what many software engineers accuse of quite some project managers not to do.
UK-AL 4y ago
Deadlines are real, but estimates are very inaccurate. The best you can do prioritise the important features. Then what gets released is what you have at the time. If you want to plan for real hard deadline with a fixed scope, you need to be giving it A LOT of time to account for unknowns and feedback cycles. I've worked in environments like you say, all they do is massively pad estimates. That's not accurate estimates, that's just hedging risk. Estimates should be taken with a pinch salt, then risk should be hedged. But they're separate things. You can't just massively hedge risk and say estimates are accurate. In fact that's more of an admission they're inaccurate.
chrisweekly 4y ago
Do you have any specific resources to recommend re: project estimates?
gabrieledarrigo 4y ago
I'm of the opposite view. I worked with many SWE teams, and estimation was, in every case, a waste of time. Deadlines and estimation don't work well for building software, especially web applications. In my experience, what works is working on lean features with a small scope, fast iteration with continuous deployment to gather rapid feedback, and constantly changing the project's scope and direction.
Spooky23 4y ago
I think some developers live in some strange land where they either don’t have enough to do or have the freedom to navel gaze at these things. From my POV, I’ve been in the tech biz for a long time and never had an issue with managing deadlines. Sometimes they need to slip, but overall, we seem to middle through.
commandlinefan 4y ago
> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible Planning how long something is going to take when you're completely in control of your own schedule is difficult but not impossible. Planning how long something is going to take when you are also expected to drop everything for every meeting or production problem that comes up is impossible.
qikInNdOutReply 4y ago
I worked in the actual, physical industry programming parts of assembly lines. Yes, such estimates are asked for and given. And yes, they are completely bollocks. So bollocks in fact, that when you arrive on project, the estimated time you gave, was already used up by other entitys like construction, eltronic engineering and various logistic problems. One can only estimate things done before. By the same person. One the exact same machine. In the exact same circumstances. And even then, the % savings of only replication after every known unknown has been eliminated, is mostly guesswork. The truth is also, that most planers constantly overrun there own project planning deadlines and the promises of their projeccts. But hey, the pope forgives himself, thats the easy part. I wish the likes of you would for just one year walk in those shoes on whose toes you usually step to apply pressure. And no, repeatetly asking for a better timeline on nailing a pudding to a wall, does not get you closer to reality. It only gives you a metric on how fast somebody insufferable gets to hear whatever he wants to hear to dissappear. And your planning and all the deadlines, are not even part of the after project renegotiations usually, were whats actually was demanded in the final form and all between forms - and what was missing is broken down into kharma and money. For constant change is even in physical projects, when things do not work out. Usually the planners are then "taken off project cause they are needed elsewhere", aka the grownup need to find a solution and they need to find it fast and efficient, without additional barking waking the real mean dogs.

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.

ahaproudowl 4y ago
Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!" Proper safety checks wouldn't let the plane leave the ground. Delays in that critical state are inconvenient, but you accept them because the alternative is not acceptable. We should treat software in exactly the same way, It's ready when it's ready. The issue is the illusion of control. A bad CEO will measure the performance of his CTO by productivity alone. A good CEO will measure the CTO's output by consistently increasing quality.
- hef19898 4y ago
  >> Yes, imagine air travel wasrun like that: "The plane must be ready by December 1st!" But that is how it is done??
  - ahaproudowl 4y ago
    The delivery date of an airplane and it's flight schedule are two completely different things. The delivery date is an estimate and the date can shift until the plane is safe to fly. The deadline for delivery is not a true deadline and the factory will only work to its safe production limit to deliver the plane. A bad practice would be to just put the plane out on the tarmac, regardless of state. It works to the safe productivity limit of the factory, not the arbitrary demand of the customer.
    - hef19898 4y ago
      Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont. And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of?
      - lmm 4y ago
        > Oh dear, do you have any idea what, say, Emirates will do to Boeing and Airbus if the promised delivery date is missed? And how airplanes are built and delivered? Hint, delivery dates are not estimates and proposals that might be met, or maybe wont. Both Boeing and Airbus have missed a bunch of delivery dates this year and will continue to do so. For some of them they're blaming regulatory approval. Guess what, it happens, life goes on, people in that industry can at least recognise that it's better than flying a plane that hasn't been approved. > And what makes you think planes don't have to safe for flight, with controls and sign offs, before take of? They do, and again the point is: what happens if the plane isn't ready? It doesn't fly until it is. They don't ignore the checks because they have a deadline.

senectus1 4y ago

funny given that only a month ago he was expounding the benefits of "Talk To Your Customers" [1] aka "Agile", which is essential artificially and programmatically governing your day via deadlines. [1] https://lucasfcosta.com/2022/08/03/talk-to-your-customers.html https://lucasfcosta.com/2022/08/03/talk-to-your-customers.ht...

Apocryphon 4y ago
The TFA still talks about talking to one's customers, so this doesn't really contradict it. > If your team can’t ship without deadlines, the lack of deadlines is not the problem. Your team’s careless attitude about customer feedback is. > When teams obsess about customer feedback, they ship as early as possible so that they can listen to their customers. > For customer-centric teams, artificial deadlines are useless because the only “deadline” that matters already exists: “as soon as possible, as long as it’s valuable.” You're choosing to conflate listening to customer feedback with Agile.
- antupis 4y ago
  Yup this you ship as fast and often as possible and then listen customer feedback. Deadlines traditional sense are working against you here because what they imply is some-kinda fixed set of features what are delivered to certain date.
- senectus1 4y ago
  >You're choosing to conflate listening to customer feedback with Agile HE draws that link... >In this post, I’ll present a robust and disruptive Agile framework. It’s called “talk to your customers” — or, in short, TTYC.

0x20cowboy 4y ago

It’s not that deadlines don’t exist (for some business reason), it’s just that trying to have both a deadline and a set of completed features is contradictory (if you want something that works well). You can set out to have a set of features, and you can have a deadline, but thinking all the features will be completed (and completed well), on that day has never worked (in my experience). You just wind up with rush hacked garbage towards the end. This is what I’ve done successfully for years now (when I am not forced by a PM to do agile): https://concentric.works/ https://concentric.works/

methyl 4y ago
That was a good read, thanks. Similar in principles to ShapeUp, which I think is one of possible implementations of Concentric. I like that it's defined loosely and you can use it as a basis for process that will fit your team.
UK-AL 4y ago
This is what agile actually wants you to do. You can have a deadline but no fixed scope, this what CI/CD is for. So when deadline day happens what you have is already released. Or you can have fixed scope but no deadline. Or you can have fixed scope & deadline, then pad things to hedge risks that might pop out. Agile prefers the first.
- Frost1x 4y ago
  >This is what agile actually wants you to do. And almost never does because it's designed in a way that's easy to abuse. Instead you often see dynamic ever-changing scope, dynamic ever tightening deadlines, and no margins for risk. Everything is on fire always and you just chase the fires around with your dev teams to put out fires, crack whips, and ask why features are behind schedule. It's madness in much of the industry.
- 0x20cowboy 4y ago
  > This is what agile actually wants you to do. Maybe, but I am not sure, and that’s not the way I’ve ever seen it done. The only way I’ve ever seen agile done is “waterfall with two week sprints”. Large wireframes of an entire application which is “unreleasable” until the end. Sure it compiles during each sprint, but it’s not a releasable product at any stage (until the mad rush at the end when all the negotiations and trade offs begin)

afarrell 4y ago

One cause of this is that we as a community have not properly shouldered the responsibility to teach good estimation skills to new engineers. It is a skill I likely now need to be able to teach —- though I still need to learn it myself.

KronisLV 4y ago

> 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. I am yet to see this done well, though hearing that it's apparently possibly has me cautiously optimistic. In my experience so far, however, I've mostly seen incomplete requirements (one could argue that a perfectly accurate spec would be no different from executable code, the end product itself), changing requirements, difficulties in estimating the impact of needing to migrate old data or accommodate/refactor old logic, little proper estimation of testing overhead, the impossibility to predict how long working with external services and integrating with them would take, especially when cross coordination with another team is necessary, the impossibility to predict what might break in regression testing or additional edge cases that might be discovered, as well as the greater impact of needing to utilize particular tech stacks (e.g. Kubernetes with a particular service mesh) due to external requirements. It's gotten to the point where I feel like adding a new form to any given application might take anywhere from 2 hours to 2 weeks, depending on what's going on in it (e.g. a well architected and simple monolith with onboarding guides and commented code vs microservices with little to no documentation, to serve as examples of different orders of magnitude of complexity). Estimations feel like just making stuff up on the go at best and like something actively harmful (being urged to make promises that are going to be false a lot of the time) at worst. The only way to do them would be not to do them - instead have some software look at the issue request and say: "Okay, you have X requirements of the following type: ..., after analyzing this project's issue history and time tracking across 5432 issues, it would appear that this issue would take between 4.2 and 7.3 days to resolve." To me it seems that if you need to be able to give accurate estimations, you'd also need a very predictable and boring tech stack across many if not all of your projects, which doesn't seem feasible in web dev, given how fast everything seems to progress and given how much CV padding one must do to remain hireable (instead of, say, using jQuery in 2022).

Existenceblinks 4y ago

I'm a type of person that can't live without deadline. If my mom doesn't say "today" in her order, I'd forget to do it.

Zanfa 4y ago

> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible. Judging by the constant stream of overdue and overbudget projects in more traditional businesses like construction, which are significantly stricter in terms of regulation, planning and have been around forever compared to software engineering, I'm not convinced accurate deadlines are possible.

6stringmerc 4y ago
Depends on the nature of the work - I recently did a gig at a civil design engineering firm and multiple projects came in at or under budget and on deadline. We’re there some serious overtime crunch periods on a couple of them? Yes, but for a multimillion dollar project with expiring Federal funds, it was achieved as set forth. I think we tend to hear more about the failures than the successes - the Omni hotels in Houston and Dallas built with bond funds were repaid years earlier than mandated because they were successful, for instance.
- Cederfjard 4y ago
  Estimates aren’t necessarily accurate just because they end up being close to reality - that could just be chance. The estimate for a project that came in substantially under budget was just as wrong as one that came in substantially over, it’s just easier to live with. If all estimates are wild-ass guesses, then some will come in on time and budget, some will undershoot and some will overshoot. I do believe that estimates, even for complex projects, are useful and can be fairly accurate, and in a lot of circumstances they can be used as the basis for deadlines, with certain considerations.
  - Frost1x 4y ago
    If "achieving" your estimate included a lot of crunch, your estimate was bad. A lot of poor estimation externalizes it's error to those trying to meet the estimate. Long hours, weekends, etc. over months while pretending the work fit on a nice paced 40 hour week with breaks is not a good estimate. Chances are, there's probably a lot of corner cutting in the final product as well, because your requirement set and associated deadline was the priority vs having a quality product delivered.

croo 4y ago

I am one of these developers. Let me give you an example of a real life consequences deadline where the project is state financed with money provided by EU, the end of the current political party term is nearing and the money is available on the premise that the project is finished successfully. "Is done" is actually approved by a third party inspector who not necceseraly works in your or the project's best interest. The project done by several separate subcontractors and if fails the political party looses faces before elections and if it fails to deliver the money provided by EU won't ever arrive and you won't get a dime. But you will pay the consequences of a failed contract. I was an IT pm/ba/architect for one of the subcontractors. This project gave third of our annual income. Should we miss it it has the chance to bankrupt the company and as a bonus you have an angry political party against you. Go, plan it, estimate it, deliver it on time. I agree that every deadline is artifical and negotiable but EU financial support deadline is a fuckin hard deadline because you cannot possibly have the necessary network and position to initiate any kind of change.

jnsaff2 4y ago

I think what you say and he says are not that different: he argues that the concept of deadlines is really pressure which is also what being not cash-rich is about, you have limited resources, therefore you have pressure to make the most out of them. So deadlines can be a lazy, dumb or crude way of pressure and may not have the intended effect. Surfacing the real reasons and dealing with them directly might be more effective.

praptak 4y ago

"then the software development output is a gating feature for real-world contractual obligations" Cool, I hope that whoever agreed to these obligations knew full well that they were taking a gamble and are prepared to deal with the consequences of the gamble not playing out. A complex software project is already a gamble. It may drag on for years even after the most pessimistic time estimate. it may totally fail (the outcome which is rarely taken into account). Drawing an arbitrary deadline on top of it just makes it a more risky gamble.

gadders 4y ago

It shows they have never worked in a regulated industry like banking. FRTB, MIFID 2, PRIIPS RTS etc etc all have/had fixed deadlines and sanctions against the company for non-compliance.

hef19898 4y ago
Or heard the term "monthly / quarterly / year end closure in places they worked at. Or faced contractual penalties for late deliveries. Or faced some deadlines caused by investors / burn rate, or any number of reasons. Or, the other way round, had to wait for someone to finish things they needed or wanted, e.g. a plumber showing up at their place to repair a leak. People refusing to commit and see those commitments through are such a pain to work with.
- gadders 4y ago
  Agreed. It's a naive view.

Singletoned 4y ago

Even his first metaphor falls down: > You can’t simply start training today and run a half marathon tomorrow, for example. You can, however, create a system in which you consistently increase the number of miles you run. The marathon will be on a specific day, ie a deadline. If you haven't finished your training before the day of the marathon, you fail.

laserlight 4y ago
Can you elaborate? I couldn't understand how the metaphor fell down. How does the existence of a deadline help me achieve it?
- Singletoned 4y ago
  Creating "a system in which you consistently increase the number of miles you run" is pointless if it doesn't get you to the point where you can run the marathon on the day that it happens. How long you have until the marathon would determine what kind of training schedule (system) you create.
  - laserlight 4y ago
    > if it doesn't get you to the point where you can run the marathon on the day that it happens. Doesn't the same logic apply to the training system that we created based on time until the marathon? Does the existence of a deadline guarantee success of a training system? And, doesn't any training system increase the number of miles consistently? Because, if I am to run 26 miles, any training regime should make me able to run 5 before 10, 10 before 26.
  - jeltz 4y ago
    Yes and no. Having more time gives you more flexibility in how to plan it so you can for example either reduce injury risk or aim at running the race at a higher pace. But it is not like you can rush it beyond a certain level. I feel one of your misconceptions is that running a marathon (or a half as in the article) is something binary. A lot of people could just go out and run a half marathon tomorrow if they were forced to. The injury risk would be high and they would feel miserable, but they would make it. A full marathon requires much more training but all marathon training programs I have seen are overkill if the goal is just to complete the race. They are instead aimed at either making people complete it at a certain pace or complete the race while being able to enjoy it. If you have a lack of time to train you can sacrifice pace/enjoyment. Rushing the training on the other hand is stupid. So for marathon training the deadline is in the form of a hard cutoff where you have to decide if you are satisfied with that little training or if you want to wait until a later race. It is more like a release train which only happens a couple of times per year. Edit: Sorry for the rant, my real point is actually that you are encouraged to change your training plan on the fly to adapt to real life events and that while the race is a deadline it is very unclear what will be delivered at it until you get pretty close to it. Will it be a 3:30 marathon or a 3:15 one? Unless you have sponsors nobody will get angry at you for not delivering what you had planned to.

laserlight 4y ago

The fact that the deadline is not “arbitrary”, because it is a contractual obligation, doesn't automatically make the contractual obligation feasible. The reasoning behind signing the contract could still be based on “arbitrary” reasons, wishful thinking, political agenda, etc. Putting project constraints on paper doesn't mean that the project will meet those constraints.

Frost1x 4y ago
A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. It's especially common in larger businesses with layers of middle management that aren't held accountable and pass their poor decision making down, often making it difficult to identify the real problem they are to the organization. Even in small orgs, if you need to make unrealistic promises to compete, you shouldn't be competing and should refocus your business, your current business plan is flawed and its not inherently your employees fault that they can't deliver as efficiently against businesses that focus on some niche and have done so over decades or benefit from economies of scale and fat margins to pad such projects they can afford to operate at a loss.
- nobody9999 4y ago
  >A lot of business leadership handwave this away and I've seen some claim the only way to remain competitive was to go this insanely aggressive towards the target in some way: low budget, short timeline, "optimistic" feature sets, etc. There's an old saw that goes something like, "fast, cheap, good. Pick two." I've found that to be true over and over again. All three options can be useful depending on whatever it is that's being worked on. Many of the complaints in this discussion about setting deadlines seems to be that not enough resources are being allocated to meet the "fast and good" selection. Which, of course leads to an end result of "fast and cheap," which isn't the goal. The main argument seems to be that "cheap and good" is better than "fast and cheap" because there aren't enough resources allocated to achieve "fast and good." The solution, of course, isn't to eschew deadlines, but rather to determine the work required and make a decision about how the work should be done (with the above being a simple-minded way of describing that 'how'). It seems like deadlines become an issue when those setting such deadlines are focused on the "fast and cheap" pair, while the folks actually doing the work want "good" to be part of that pairing. As someone who has worked both in environments which focus on minimizing time and cost when bidding for work, and in those where estimates realistically reflect the time and cost of completing the work, I find the latter to be much more effective. The former is generally a shit show where no one is happy. The client either doesn't get what they need, or it's going to cost a whole bunch more than they were told, and those actually doing the work are pressed to work harder and faster because the client is pissed off. And the business generally loses in the medium to long term as well, as they're unlikely to get repeat business and certainly won't get referrals from that client. When good estimates are provided and the appropriate resources applied, projects often go much more smoothly and everyone wins -- over the short, medium and long term. Obviously this requires good planning and a strong understanding of the goals and requirements and translating those into reasonably accurate estimates. Those (as others on this thread pointed out) are skills that can be learned. Sadly, those skills seem to be in short supply. And more's the pity. Edit: Clarified my prose.

wruza 4y ago

Correct when true. But if talking about all deadlines, you can sort them by category. One that I especially don’t like are populistic deadlines, when team burnout is used to: impress or brag before someone, get some quick results only to spend few weeks before even looking into it, set out of a thin air in a project of an RnD nature. Deadline is not only a planning instrument, it is also a force that allows to tick the box regardless of a true state. You cannot always expect them to be used in a sensible way, because other departments and heads suck as much as you do, or more, if they are further from physical/informational reality. Tight budget means tight planning, but it might also mean that your chiefs are simply underperforming. Working on the edge of bankruptcy for years, never seen my “push hard this week (or: this sunday) it’s important to us” taken as important or used right away. I even learned to detect with high probability when the rush is based on cocaine and can be safely ignored. This is not a rebuttal (I agree that deadlines are useful), it’s just the back side of this shiny coin of “effective management”.

traceroute66 4y ago

> It’s always fascinating to read these anti-deadline articles that assume deadlines are arbitrary things that exist for no reason. The one thing I hate more than that, is articles such as this one that waffle on for eternity using pseudo-science. For example, what do all the pretty graphs and paragraphs of waffle about coin tosses have to do with the price of eggs ? Its basically space padding that doesn't add anything to the argument they are trying to make.

koonsolo 4y ago

Your explanation sound reasonable, except for the fact that you seem to mix estimates and deadlines together. I don't trust the planning of anyone how doesn't make a big distinction between estimates and deadlines. So I would like to know how your development environment deals with this.

q-big 4y ago

> In that case, target dates must be carefully forecasted and estimates must be performed with great care and detain. That is exactly what many software engineers accuse of quite some project managers not to do.

UK-AL 4y ago

Deadlines are real, but estimates are very inaccurate. The best you can do prioritise the important features. Then what gets released is what you have at the time. If you want to plan for real hard deadline with a fixed scope, you need to be giving it A LOT of time to account for unknowns and feedback cycles. I've worked in environments like you say, all they do is massively pad estimates. That's not accurate estimates, that's just hedging risk. Estimates should be taken with a pinch salt, then risk should be hedged. But they're separate things. You can't just massively hedge risk and say estimates are accurate. In fact that's more of an admission they're inaccurate.

chrisweekly 4y ago

Do you have any specific resources to recommend re: project estimates?

gabrieledarrigo 4y ago

I'm of the opposite view. I worked with many SWE teams, and estimation was, in every case, a waste of time. Deadlines and estimation don't work well for building software, especially web applications. In my experience, what works is working on lean features with a small scope, fast iteration with continuous deployment to gather rapid feedback, and constantly changing the project's scope and direction.

Spooky23 4y ago

I think some developers live in some strange land where they either don’t have enough to do or have the freedom to navel gaze at these things. From my POV, I’ve been in the tech biz for a long time and never had an issue with managing deadlines. Sometimes they need to slip, but overall, we seem to middle through.

commandlinefan 4y ago

> Estimation, planning, and progress tracking are difficult skills that must be learned, but they’re not impossible Planning how long something is going to take when you're completely in control of your own schedule is difficult but not impossible. Planning how long something is going to take when you are also expected to drop everything for every meeting or production problem that comes up is impossible.

qikInNdOutReply 4y ago

I worked in the actual, physical industry programming parts of assembly lines. Yes, such estimates are asked for and given. And yes, they are completely bollocks. So bollocks in fact, that when you arrive on project, the estimated time you gave, was already used up by other entitys like construction, eltronic engineering and various logistic problems. One can only estimate things done before. By the same person. One the exact same machine. In the exact same circumstances. And even then, the % savings of only replication after every known unknown has been eliminated, is mostly guesswork. The truth is also, that most planers constantly overrun there own project planning deadlines and the promises of their projeccts. But hey, the pope forgives himself, thats the easy part. I wish the likes of you would for just one year walk in those shoes on whose toes you usually step to apply pressure. And no, repeatetly asking for a better timeline on nailing a pudding to a wall, does not get you closer to reality. It only gives you a metric on how fast somebody insufferable gets to hear whatever he wants to hear to dissappear. And your planning and all the deadlines, are not even part of the after project renegotiations usually, were whats actually was demanded in the final form and all between forms - and what was missing is broken down into kharma and money. For constant change is even in physical projects, when things do not work out. Usually the planners are then "taken off project cause they are needed elsewhere", aka the grownup need to find a solution and they need to find it fast and efficient, without additional barking waking the real mean dogs.