4 ms·

You need some estimates if you need to sync the efforts of two or more teams. For single teams with single deliverable there might be a necessity to set a date,

by fsloth 6y ago

You need some estimates if you need to sync the efforts of two or more teams. For single teams with single deliverable there might be a necessity to set a date, or might not. But if there is no external reason to push for a date then setting an arbitrary internal date when it provides no additional value is just silly.

convolvatron 6y ago
been thinking about this because my current project has suffered from management repeatedly setting unreasonable dates. which causes flailing to get stuff put in, and then we the date finally gets moved out, more stuff to paper over that crappy stuff. but you have to admit that without a date developers will just noodle around forever. I think the only recourse is to constantly be evaluating the current slate and the date and keep sliding it out as necessary or throw stuff off the train. really, you should never miss a date. you should have realized some time ago that it wasn't going to happen and slid it out already.
- Twisol 6y ago
  > you have to admit that without a date developers will just noodle around forever. This seems more a statement about extrinsic motivation than dates in particular. Dates are the most obvious blunt instrument for applying extrinsic motivation, but there are others. Intrinsic motivation is in some ways even better. You can't force someone to be intrinsically motivated to achieve something... but pushy dates and expectations can decimate any motivation that was already there.
- fsloth 6y ago
  "but you have to admit that without a date developers will just noodle around forever." Speaking for myself as a software engineer I have only seldom fixed dates and deliver constantly. My main goal is to deliver value to the party I work for and my end users. True artists ship. On the other hand, I do stall occasionally. It's because I don't understand something, and rather than just ship some random junk I try to make my junk do the right thing. To an outside observer this carefull design - engineering if you will - is quite indistinguishable from noodling. If you put an arbitrary date for me then you will just get bad code and that is a bad deal for everyone. There are times when the date is fixed. Then you haul ass and raze mountains to ship, no matter how ugly the result. If the date is constantly set to some random date I have no idea should I dial quality down and increase velocity or vice versa. Therefore a constant fixed date will just get worse quality, even if there was no good reason to hurry. I think you meant to say how to have enough transparency so that everyone is honest and accountable. You don't need imaginary dates for that. Just have people report at fixed cadence what they've done. Good people remember they need to explain what they've done and dont wander off into the wilderness for no good reason. This is sufficient to keep everyone on the right track in almost any environment. Now you say - "Aha! But what about the occasional person who is incapable of doing their job! How do we point him out!" - to which I answer: If you need to design your development process to safeguard against botched hiring since they seem to do it constantly you really need to fix your hiring. Good people will detect a rotten egg eventually and there should be ways to deal with this outside of regular project cadence. If you try to micromanage great engineers and programmers you are just wasting talent and eventually everyone will just move on and all you have left are the rotten eggs.
deleted 6y ago
[deleted]

by fsloth 6y ago

convolvatron 6y ago

been thinking about this because my current project has suffered from management repeatedly setting unreasonable dates. which causes flailing to get stuff put in, and then we the date finally gets moved out, more stuff to paper over that crappy stuff. but you have to admit that without a date developers will just noodle around forever. I think the only recourse is to constantly be evaluating the current slate and the date and keep sliding it out as necessary or throw stuff off the train. really, you should never miss a date. you should have realized some time ago that it wasn't going to happen and slid it out already.

Twisol 6y ago
> you have to admit that without a date developers will just noodle around forever. This seems more a statement about extrinsic motivation than dates in particular. Dates are the most obvious blunt instrument for applying extrinsic motivation, but there are others. Intrinsic motivation is in some ways even better. You can't force someone to be intrinsically motivated to achieve something... but pushy dates and expectations can decimate any motivation that was already there.
fsloth 6y ago
"but you have to admit that without a date developers will just noodle around forever." Speaking for myself as a software engineer I have only seldom fixed dates and deliver constantly. My main goal is to deliver value to the party I work for and my end users. True artists ship. On the other hand, I do stall occasionally. It's because I don't understand something, and rather than just ship some random junk I try to make my junk do the right thing. To an outside observer this carefull design - engineering if you will - is quite indistinguishable from noodling. If you put an arbitrary date for me then you will just get bad code and that is a bad deal for everyone. There are times when the date is fixed. Then you haul ass and raze mountains to ship, no matter how ugly the result. If the date is constantly set to some random date I have no idea should I dial quality down and increase velocity or vice versa. Therefore a constant fixed date will just get worse quality, even if there was no good reason to hurry. I think you meant to say how to have enough transparency so that everyone is honest and accountable. You don't need imaginary dates for that. Just have people report at fixed cadence what they've done. Good people remember they need to explain what they've done and dont wander off into the wilderness for no good reason. This is sufficient to keep everyone on the right track in almost any environment. Now you say - "Aha! But what about the occasional person who is incapable of doing their job! How do we point him out!" - to which I answer: If you need to design your development process to safeguard against botched hiring since they seem to do it constantly you really need to fix your hiring. Good people will detect a rotten egg eventually and there should be ways to deal with this outside of regular project cadence. If you try to micromanage great engineers and programmers you are just wasting talent and eventually everyone will just move on and all you have left are the rotten eggs.

deleted 6y ago

[deleted]