I work at a news site. They’re going to hold the election on a certain day whether I’m ready for it or not. Obviously then the goal is to make an actionable design that can be implemented far enough in advance before the election day to do some testing and whatnot. You can call it what you like, but it’s basically a deadline.
Of course, lots of work I do has no deadline. The CMS is upgraded when the CMS is upgraded. So I think it’s worth distinguishing things with real externally imposed deadlines from things with internal goal dates. Goal dates can be shifted. Deadlines are not so easy to move.
I used to work for a edtech company. If features weren’t ready by the start of the school year we’d miss our chance to get the majority of our teachers properly onboarded. Deadlines matter in software because they matter in the meatworld.
The fact that you have to deliver a specific feature for election day is a choice made by humans, not something inevitable. The decision to develop something new before a given date instead of saying “we develop the feature and at the first useful election we use it” is a choice. Deadlines become inevitable when profit is put before software quality. Deadlines are inevitable when people that care about profit hold more power than people that care about software quality.
Are you saying that deadlines happen when people care more about profit than software quality but not when people care more about revenue than software quality?
it depends on the context and mission of the organization but in my experience, in non-profit orgs it’s much easier to reason long term compared to VC-funded startups or big corpos.
Deadlines are also inevitable when the food is going to spoil unless we have a system for distributing it by a certain date. That doesn’t have anything to do with profits, it has to do with the food spoiling; it would spoil just as fast under any kind of system humans can come up with.
“we develop the feature and at the first useful election we use it”
I know that Politico takes that approach because they cover lots of elections nationwide. For me, I’m only covering Pennsylvania, so there’s not really enough chance to recoup investment. If we miss 2022, there’s no telling if we’ll even be using the same CMS in 2024. It would be like trying to get the kids ready for school on Sunday morning: you can do some things, for sure, but lots of it really can only be done on Monday morning.
I generally agree, it’s part of the system the engineer is operating inside of…they are linked. It’s the reality we often brush off or ignore. Instead, we tell ourselves (and our customers) this software was “made with 💖” and “we’re making the world a better place.” Fine attitude for a pet project you control, but when you work for a company that’s beholden to VC money or the public stock market, good luck.
So I think it’s worth distinguishing things with real externally imposed deadlines from things with internal goal dates.
Failure to do this effectively has been the cause of so many Dilbertesque own-goals - including some of my own - over the several decades I’ve been part of the industry.
It’s doubly important for senior leaders. I’ve seen a “gee it would be nice if we had this by $DATE” turn through a series of retellings into a hard deadline, and then eventually horrify the person who spoke off-the-cuff when she discovered how that comment had been taken.
Distinguishing deadline vs goal date is a good clarification.
If you look at what the article is espousing, it’s exactly what you would want to do with a real deadline: check in regularly on where you are, decide what gets done and what doesn’t get done, and bulldoze everything else out of the way.
Invoking the halting problem’s a bit problematic, because we write many, many programs where we do know when they will finish. We have whole languages (Datalog) that are guaranteed to terminate.
Though most of what I see in articles like this is what the agile community figured out long ago. I still haven’t figured out what the balance of what happened to agile was among sabotage, misunderstanding, or Gresham’s law.
Sometimes I read something like this and imagine the author got in big trouble and chose to spend a few thousand words explaining why the thing they got in trouble for shouldn’t be a thing they can get in trouble for.
Agreed. The reason deadlines exist is that multiple people need to coordinate. This is much more obvious in physical products where multiple pieces literally have to come together at the right place at the right time, and there are physical costs associated with either storing surplus or waiting for one part to be supplied. But it’s still true in software systems: you need developers building the system, developers building support stuff for the system (specialized tooling, installers, etc), you need devops building and running the infrastructure for it, you need to give testing/QA (if any) sufficient time to hammer on it, customer support time to get trained on it, even marketing (hrk, ptui) needs to know when to put up the posts announcing releases or changes.
Now not all systems need all these things, and in software there’s a fair bit more soft wiggle room around these than if, say, you have a shipping container full of stuff sitting in a port and they’re charging you $X per day for storage. But they still exist. The deadline is not about you, it’s about making all the pieces fit together.
The fact that this seems to be so seldom communicated properly and the feedback and timing on deadlines is so dysfunctional is its own problem, of course.
Or maybe it’s full of people out there that don’t use deadlines and are appalled by how many still do. Or it’s just a way to stimulate healthier desires in our colleagues to make the whole industry a bit better.
This kind of essay could only exist in an industry like ours, where so many are determined for relatively arbitrary reasons. Yes, there is a time T where this software needs to be written or else it’ll be useless, but the value of T is almost completely unknowable before it has passed. So we feel forced to assume that T might be “tomorrow” and pull another all-nighter.
The article seems to start with a surprising premise: that deadlines are things that are used by software engineers. I think this is somewhat missing the point. Deadlines are used by software engineering managers. They exist so that people doing resource allocation understand what is required. Without a deadline, any software engineering project could be accomplished with a single engineer assigned and no other resources except a cheap laptop. Deadlines tell you that you are going to need to split the work up among people, that you are going to need to have some process for coordination so that adding more people actually speeds things up, and so on. They also let you know whether a project is feasible at all. If it takes a month to onboard someone, you have the capacity to onboard only three people at a time, and you need to ship a feature that will require five more productive engineers with a deadline of six weeks from now, you can’t do it. A competent project manager will then use that information in the opposite direction to rearrange other bits of schedule so that there is an achievable deadline and other things get short-term priority.
I work at a news site. They’re going to hold the election on a certain day whether I’m ready for it or not. Obviously then the goal is to make an actionable design that can be implemented far enough in advance before the election day to do some testing and whatnot. You can call it what you like, but it’s basically a deadline.
Of course, lots of work I do has no deadline. The CMS is upgraded when the CMS is upgraded. So I think it’s worth distinguishing things with real externally imposed deadlines from things with internal goal dates. Goal dates can be shifted. Deadlines are not so easy to move.
I used to work for a edtech company. If features weren’t ready by the start of the school year we’d miss our chance to get the majority of our teachers properly onboarded. Deadlines matter in software because they matter in the meatworld.
The fact that you have to deliver a specific feature for election day is a choice made by humans, not something inevitable. The decision to develop something new before a given date instead of saying “we develop the feature and at the first useful election we use it” is a choice. Deadlines become inevitable when profit is put before software quality. Deadlines are inevitable when people that care about profit hold more power than people that care about software quality.
Profit is more important than software quality. Without profit, people don’t get paid.
that’s revenue. Profit is what pays your manager’s yacht. I work in a non-profit and I get paid every month.
Also it’s not true: in start-up economy is not really important to turn a profit. But it’s not the best driver of software quality either.
Are you saying that deadlines happen when people care more about profit than software quality but not when people care more about revenue than software quality?
it depends on the context and mission of the organization but in my experience, in non-profit orgs it’s much easier to reason long term compared to VC-funded startups or big corpos.
Deadlines are also inevitable when the food is going to spoil unless we have a system for distributing it by a certain date. That doesn’t have anything to do with profits, it has to do with the food spoiling; it would spoil just as fast under any kind of system humans can come up with.
It’s quite OT but the logistics of food greatly impact on the spoilage of food in different ways.
I know that Politico takes that approach because they cover lots of elections nationwide. For me, I’m only covering Pennsylvania, so there’s not really enough chance to recoup investment. If we miss 2022, there’s no telling if we’ll even be using the same CMS in 2024. It would be like trying to get the kids ready for school on Sunday morning: you can do some things, for sure, but lots of it really can only be done on Monday morning.
I generally agree, it’s part of the system the engineer is operating inside of…they are linked. It’s the reality we often brush off or ignore. Instead, we tell ourselves (and our customers) this software was “made with 💖” and “we’re making the world a better place.” Fine attitude for a pet project you control, but when you work for a company that’s beholden to VC money or the public stock market, good luck.
Failure to do this effectively has been the cause of so many Dilbertesque own-goals - including some of my own - over the several decades I’ve been part of the industry.
It’s doubly important for senior leaders. I’ve seen a “gee it would be nice if we had this by $DATE” turn through a series of retellings into a hard deadline, and then eventually horrify the person who spoke off-the-cuff when she discovered how that comment had been taken.
Indeed – this seems to.me like the difference between a deadline and good old wishful thinking!
Distinguishing deadline vs goal date is a good clarification.
If you look at what the article is espousing, it’s exactly what you would want to do with a real deadline: check in regularly on where you are, decide what gets done and what doesn’t get done, and bulldoze everything else out of the way.
Invoking the halting problem’s a bit problematic, because we write many, many programs where we do know when they will finish. We have whole languages (Datalog) that are guaranteed to terminate.
Though most of what I see in articles like this is what the agile community figured out long ago. I still haven’t figured out what the balance of what happened to agile was among sabotage, misunderstanding, or Gresham’s law.
Sometimes I read something like this and imagine the author got in big trouble and chose to spend a few thousand words explaining why the thing they got in trouble for shouldn’t be a thing they can get in trouble for.
Agreed. The reason deadlines exist is that multiple people need to coordinate. This is much more obvious in physical products where multiple pieces literally have to come together at the right place at the right time, and there are physical costs associated with either storing surplus or waiting for one part to be supplied. But it’s still true in software systems: you need developers building the system, developers building support stuff for the system (specialized tooling, installers, etc), you need devops building and running the infrastructure for it, you need to give testing/QA (if any) sufficient time to hammer on it, customer support time to get trained on it, even marketing (hrk, ptui) needs to know when to put up the posts announcing releases or changes.
Now not all systems need all these things, and in software there’s a fair bit more soft wiggle room around these than if, say, you have a shipping container full of stuff sitting in a port and they’re charging you $X per day for storage. But they still exist. The deadline is not about you, it’s about making all the pieces fit together.
The fact that this seems to be so seldom communicated properly and the feedback and timing on deadlines is so dysfunctional is its own problem, of course.
Or maybe it’s full of people out there that don’t use deadlines and are appalled by how many still do. Or it’s just a way to stimulate healthier desires in our colleagues to make the whole industry a bit better.
This kind of essay could only exist in an industry like ours, where so many are determined for relatively arbitrary reasons. Yes, there is a time T where this software needs to be written or else it’ll be useless, but the value of T is almost completely unknowable before it has passed. So we feel forced to assume that T might be “tomorrow” and pull another all-nighter.
The article seems to start with a surprising premise: that deadlines are things that are used by software engineers. I think this is somewhat missing the point. Deadlines are used by software engineering managers. They exist so that people doing resource allocation understand what is required. Without a deadline, any software engineering project could be accomplished with a single engineer assigned and no other resources except a cheap laptop. Deadlines tell you that you are going to need to split the work up among people, that you are going to need to have some process for coordination so that adding more people actually speeds things up, and so on. They also let you know whether a project is feasible at all. If it takes a month to onboard someone, you have the capacity to onboard only three people at a time, and you need to ship a feature that will require five more productive engineers with a deadline of six weeks from now, you can’t do it. A competent project manager will then use that information in the opposite direction to rearrange other bits of schedule so that there is an achievable deadline and other things get short-term priority.