8 ms·

As a person who runs a small software business, coding most of the functionality myself, I actually disagree with the article. There is a huge value in setting

As a person who runs a small software business, coding most of the functionality myself, I actually disagree with the article. There is a huge value in setting deadlines because they force you to prioritize things. Once you realize that you don't have the time to ship features X, Y and Z, you start comparing their impact/complexity/risks, pick the most beneficial one, and ship it before it's too late. Without prioritization it's very easy to get stuck in a loop of endlessly adding small improvements/testing new ideas, but never releasing the final sellable product. There are a few notorious examples from the game industry where no time pressure lead to either no product, or a hopelessly late-to-market product (e.g. Half-Life 3, Duke Nukem Forever). There are more smaller examples where entire teams endlessly juggle the code between web frameworks, as they come in and out of fashion, and neglect more user-impacting features. That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact.

NullPrefix 6y ago
>Half-Life 3 I'm not sure they even worked on it, have they?
- ShamelessC 6y ago
  They worked on Half Life 2: Episode 3 for awhile before giving up. There was also a leak of unfinished Half Life 3 source code in 2014 (I think). After the release of Half Life Alyx a few months ago, they have heavily implied a recommitment to Half Life 3 in interviews.
silentific 6y ago
"Arbitrary date". Deadlines are still important.
tikhonj 6y ago
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.
temac 6y ago
> As a person who runs a small software business, coding most of the functionality myself I'm not even sure you disagree with the article, given you are in a radically different position; how often do you think, as an implementer, that your business ideas are complete bullshit, sometimes even just because you don't know all the details you are thinking about on the business side? Project management is about communication. Having that problem reduced to communicating mainly with yourself changes a little what is effective and what is not. > That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact. So yeah, we could continue to interpret that as you mainly agreeing. Implicit cultural incentives are a thing and it is illusory to think that "devs" won't be aware of schedules and won't drop half of unit tests if there is a risk of looking "bad" at short term if they stuck with state-of-the-art practices. Note that the solution is not in the extreme opposite, of course. It never is. There is a system of values to be tuned, and I'm not sure a lot of projects exist where the date of completion does not matter at all. Your example of Duke Nukem Forever was on point :) But being date driven would mean the date is the most important thing: this also is rarely the case.
nbardy 6y ago
Agreed. Maybe at a large organization where you are working on system that have more concern about stability and maintenance. At a startup setting deadlines and cutting corners is key for me to be a good engineer. My goal is get to "something" in the hands of a user or customer as fast as possible to determine what I actually need to build vs what I think I need to build. Cutting corners and getting out features faster allows me to validate what I'm building is useful and better direction for what I'm building next. Before my current project is designing an API for logging and viewing image segmentation masks, A mask that segments an image into n classes. We started with a large design that allowed users to configure to masks in different layers. Toggle them on and off and do composting. Instead of building this exactly I shipped a small fast very that renders images with masks and adds some toggles for each class. Turns out one of our main assumptions was wrong we thought the number of classes(n) would be small. It's 1-2 order of magnitude larger on average for all of our users. And sorting through large amounts of classes is the biggest issue our users are clamoring for. Now instead of spending a bunch of time building a UI for editing the masks. We first focused on handing large counts of classes usefully. As well, all of the different settings for mask composition and layout we dreamed up really don't matter. While there is 100's of different ways you can layout and compost the masks. Turns out there is 3 default layouts that everyone wants, we don't need a UI for tweaking layouts we just need a toggle between the three common states. Instead of spending extra time to get it right. We aggressively cut scope and shipped a not particularly useful feature. We got two big benefits out of this. We ended up building something much smaller in scope than our initial design and we ended up building something better and more useful.
kelnos 6y ago
Agree wholeheartedly. If you don't trust your people to come up with reasonable time estimates, you should fire them and find people you do trust. If you do trust them, then you shouldn't play stupid games to get them to shrink their estimates. If you want 20 features, but the estimates don't give you the delivery date you want, your only reasonable option is to cut features until the team believes that the remaining features can be done by the deadline, based on their original estimates. I think it's also potentially reasonable to say "I really need these 20 features, and I'm ok if you cut corners on quality to get me those 20 features by this date". But in my experience, I've never heard anyone say that and mean it; they still get pissed off when the end result is buggy as hell. And I just don't think it's a good business decision anyway; burning customer goodwill is only a winning strategy when you're a monopolist, and even then only until you get unseated, as everyone eventually does, given time.
wpietri 6y ago
> There is a huge value in setting deadlines because they force you to prioritize things. This can be true, but only if the team is not otherwise good at prioritizing things. And although deadlines do create pressure once they get near, they often create a feeling of slack when they're still far out. They also create a feeling of slack after they pass.
- 7532yahoogmail 6y ago
  Consider a team of 8 who suck at estimation. Three questions: 1) is anybody aware the team sucks? 2) if yes are people open about it? If no, why not? 3) now what?
  - wpietri 6y ago
    1) Probably, 2) possibly, and 3) they should use a method that doesn't rely on estimation.
    - 7532yahoogmail 6y ago
      Please elaborate on (3)
      - wpietri 6y ago
        Estimation is only valuable in narrow circumstances. One has to know the expected return with a fair bit of precision to do ROI calculations; generally business revenues projections are highly imprecise, so estimation is often a waste. Reliable estimation requires a fair bit of information. The technologies have to be well understood. The team has to have worked together sufficiently. The business needs user impact has to be well researched. Estimates can't be more precise than any of those things. Further, estimation requires stability in team, technology, user needs, business environment, and competitor behavior. To the extent that any of those things are expected to change, estimates become less and less worthwhile. Lastly, estimation assumes that nobody will learn anything significant over the course of the project. That's surely true for some domains. But in quite a lot of areas, especially the startups we focus on here, the whole point is to learn new things. We see how technologies perform, and then make new choices. We test user reaction, and then change product plans. When that happens, estimates quickly become stale. So when we're in situations where estimates aren't particularly useful, we have to use different methods. Personally my favorite is using the Lean Startup framework and updated versions the Extreme Programming practices, especially Continuous Deployment. I have an older talk on some of this here: https://vimeo.com/24843552 https://vimeo.com/24843552 And I've written some about it here: http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/ I hope that helps! I may not check this far back in the HN comments again, but feel free to email if you'd like to discuss it further.

NullPrefix 6y ago

>Half-Life 3 I'm not sure they even worked on it, have they?

ShamelessC 6y ago
They worked on Half Life 2: Episode 3 for awhile before giving up. There was also a leak of unfinished Half Life 3 source code in 2014 (I think). After the release of Half Life Alyx a few months ago, they have heavily implied a recommitment to Half Life 3 in interviews.

silentific 6y ago

"Arbitrary date". Deadlines are still important.

tikhonj 6y ago

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.

temac 6y ago

> As a person who runs a small software business, coding most of the functionality myself I'm not even sure you disagree with the article, given you are in a radically different position; how often do you think, as an implementer, that your business ideas are complete bullshit, sometimes even just because you don't know all the details you are thinking about on the business side? Project management is about communication. Having that problem reduced to communicating mainly with yourself changes a little what is effective and what is not. > That said, most of time pressure should only be applied at the decision-making level. Once you have decided to ship feature X with framework Y, it's useless to nag on your devs to do it in half the time by dropping unit tests, or doing 60-hour work weeks. Instead, you should have picked feature Z with 50% the complexity and 80% user impact. So yeah, we could continue to interpret that as you mainly agreeing. Implicit cultural incentives are a thing and it is illusory to think that "devs" won't be aware of schedules and won't drop half of unit tests if there is a risk of looking "bad" at short term if they stuck with state-of-the-art practices. Note that the solution is not in the extreme opposite, of course. It never is. There is a system of values to be tuned, and I'm not sure a lot of projects exist where the date of completion does not matter at all. Your example of Duke Nukem Forever was on point :) But being date driven would mean the date is the most important thing: this also is rarely the case.

nbardy 6y ago

Agreed. Maybe at a large organization where you are working on system that have more concern about stability and maintenance. At a startup setting deadlines and cutting corners is key for me to be a good engineer. My goal is get to "something" in the hands of a user or customer as fast as possible to determine what I actually need to build vs what I think I need to build. Cutting corners and getting out features faster allows me to validate what I'm building is useful and better direction for what I'm building next. Before my current project is designing an API for logging and viewing image segmentation masks, A mask that segments an image into n classes. We started with a large design that allowed users to configure to masks in different layers. Toggle them on and off and do composting. Instead of building this exactly I shipped a small fast very that renders images with masks and adds some toggles for each class. Turns out one of our main assumptions was wrong we thought the number of classes(n) would be small. It's 1-2 order of magnitude larger on average for all of our users. And sorting through large amounts of classes is the biggest issue our users are clamoring for. Now instead of spending a bunch of time building a UI for editing the masks. We first focused on handing large counts of classes usefully. As well, all of the different settings for mask composition and layout we dreamed up really don't matter. While there is 100's of different ways you can layout and compost the masks. Turns out there is 3 default layouts that everyone wants, we don't need a UI for tweaking layouts we just need a toggle between the three common states. Instead of spending extra time to get it right. We aggressively cut scope and shipped a not particularly useful feature. We got two big benefits out of this. We ended up building something much smaller in scope than our initial design and we ended up building something better and more useful.

kelnos 6y ago

Agree wholeheartedly. If you don't trust your people to come up with reasonable time estimates, you should fire them and find people you do trust. If you do trust them, then you shouldn't play stupid games to get them to shrink their estimates. If you want 20 features, but the estimates don't give you the delivery date you want, your only reasonable option is to cut features until the team believes that the remaining features can be done by the deadline, based on their original estimates. I think it's also potentially reasonable to say "I really need these 20 features, and I'm ok if you cut corners on quality to get me those 20 features by this date". But in my experience, I've never heard anyone say that and mean it; they still get pissed off when the end result is buggy as hell. And I just don't think it's a good business decision anyway; burning customer goodwill is only a winning strategy when you're a monopolist, and even then only until you get unseated, as everyone eventually does, given time.

wpietri 6y ago

> There is a huge value in setting deadlines because they force you to prioritize things. This can be true, but only if the team is not otherwise good at prioritizing things. And although deadlines do create pressure once they get near, they often create a feeling of slack when they're still far out. They also create a feeling of slack after they pass.

7532yahoogmail 6y ago
Consider a team of 8 who suck at estimation. Three questions: 1) is anybody aware the team sucks? 2) if yes are people open about it? If no, why not? 3) now what?
- wpietri 6y ago
  1) Probably, 2) possibly, and 3) they should use a method that doesn't rely on estimation.
  - 7532yahoogmail 6y ago
    Please elaborate on (3)
    - wpietri 6y ago
      Estimation is only valuable in narrow circumstances. One has to know the expected return with a fair bit of precision to do ROI calculations; generally business revenues projections are highly imprecise, so estimation is often a waste. Reliable estimation requires a fair bit of information. The technologies have to be well understood. The team has to have worked together sufficiently. The business needs user impact has to be well researched. Estimates can't be more precise than any of those things. Further, estimation requires stability in team, technology, user needs, business environment, and competitor behavior. To the extent that any of those things are expected to change, estimates become less and less worthwhile. Lastly, estimation assumes that nobody will learn anything significant over the course of the project. That's surely true for some domains. But in quite a lot of areas, especially the startups we focus on here, the whole point is to learn new things. We see how technologies perform, and then make new choices. We test user reaction, and then change product plans. When that happens, estimates quickly become stale. So when we're in situations where estimates aren't particularly useful, we have to use different methods. Personally my favorite is using the Lean Startup framework and updated versions the Extreme Programming practices, especially Continuous Deployment. I have an older talk on some of this here: https://vimeo.com/24843552 https://vimeo.com/24843552 And I've written some about it here: http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/ I hope that helps! I may not check this far back in the HN comments again, but feel free to email if you'd like to discuss it further.