"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.
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.