3 ms·

Prioritization is the key thing. I have a simple rule of thumb: a deadline is a "real deadline" if I would reduce scope to hit the deadline. A deadline is jus

Prioritization is the key thing. I have a simple rule of thumb: a deadline is a "real deadline" if I would reduce scope to hit the deadline. A deadline is just a goal if I would not be able (or willing) to reduce scope to hit it. Treating a date as an absolute deadline without being able to adjust scope is where productive work gets totally derailed.

mmcnl 6y ago
Great insight. A deadline where the only thing you can change is the hours you put in, is not a deadline, it's exploitation.
- troebr 6y ago
  There are multiple ways to make a project fit into a deadline: - change/reduce the scope => lowers the value of the product - cut corners: for ex. skip testing, ignore bugs, work faster, skip code reviews, etc. => lower quality - work longer hours (lower quality + human cost) - throw more resources at the problem: may scale poorly if at all, as well as usually results in lower quality and more friction, aka human cost It's all about weighing everything and making the right trade-offs. Sometimes short term solutions are the right approach, maybe you need a POC more than a polished product to get that next round of funding or something. I've struggled with that in the past, and next time I'm presented with this kind of project, I'll clearly explain the trade-offs, for example translating lower quality to: this may increase the number of bug reports significantly, increase the maintenance cost, prevent the addition of other features with significant overhauls, this and this engineer may start looking for another job, etc.
- Frost1x 6y ago
  It's incredibly common and a sign of poor management and structures I have no desire of working with. It's also what most "agile" environments end up turning into: a bunch of inflexible arbitrary deadlines designed to make developers work more, amongst many other problems.
mikekchar 6y ago
One other important thing to realise: prioritisation is the art of deciding what you are not going to do. When you prioritise, you place the highest value/risk things at the beginning. That way, when you run out of time, those things have been done. You put the lowest value things at the bottom. That way when you run out of time, those things have not been done. I forget who I saw do this (it may have been Nat Pryce at a talk somewhere). He took a list of the items that needed to get done. He rendered the first item with full opacity. With each subsequent item, he reduced the opacity. At the end of the list, the items were invisible. Then he said, "This is roughly the likelihood of me getting these things done." It's a mistake to draw a line on your list where you think the deadline will fall, because then you are fixing your scope as well as your time. But if each day you adjust the opacity of your list, hopefully people will get the point.

mmcnl 6y ago

Great insight. A deadline where the only thing you can change is the hours you put in, is not a deadline, it's exploitation.

troebr 6y ago
There are multiple ways to make a project fit into a deadline: - change/reduce the scope => lowers the value of the product - cut corners: for ex. skip testing, ignore bugs, work faster, skip code reviews, etc. => lower quality - work longer hours (lower quality + human cost) - throw more resources at the problem: may scale poorly if at all, as well as usually results in lower quality and more friction, aka human cost It's all about weighing everything and making the right trade-offs. Sometimes short term solutions are the right approach, maybe you need a POC more than a polished product to get that next round of funding or something. I've struggled with that in the past, and next time I'm presented with this kind of project, I'll clearly explain the trade-offs, for example translating lower quality to: this may increase the number of bug reports significantly, increase the maintenance cost, prevent the addition of other features with significant overhauls, this and this engineer may start looking for another job, etc.
Frost1x 6y ago
It's incredibly common and a sign of poor management and structures I have no desire of working with. It's also what most "agile" environments end up turning into: a bunch of inflexible arbitrary deadlines designed to make developers work more, amongst many other problems.

mikekchar 6y ago

One other important thing to realise: prioritisation is the art of deciding what you are not going to do. When you prioritise, you place the highest value/risk things at the beginning. That way, when you run out of time, those things have been done. You put the lowest value things at the bottom. That way when you run out of time, those things have not been done. I forget who I saw do this (it may have been Nat Pryce at a talk somewhere). He took a list of the items that needed to get done. He rendered the first item with full opacity. With each subsequent item, he reduced the opacity. At the end of the list, the items were invisible. Then he said, "This is roughly the likelihood of me getting these things done." It's a mistake to draw a line on your list where you think the deadline will fall, because then you are fixing your scope as well as your time. But if each day you adjust the opacity of your list, hopefully people will get the point.