I tend to take a fairly dynamic approach to design.
In many cases; especially where you have heterogenous projects, done by multi-disciplinary teams, dated milestones are pretty much required. You have to have some thing, by some time. I worked like that for many years, as part of massive, multi-national teams.
But these days, I have the "luxury" of generally working alone, or as a member of a casual open-source team that doesn't have any specific deliverable deadlines.
What I do, is define what "done" looks like, and set some very fuzzy milestones. At each of these inflection points, I reexamine the work I'm doing. In some cases, I decide to bin the whole effort, and either rewrite it, or simply scrag it, and move on to the next in the FIFO. In other cases (less often than I'd like), I am ahead of expected schedule, or the functionality of my work is better than expected. Boo-Ya. Go Me.
The important thing for me, is that I have a solid idea of a deliverable. It may not be associated with a date, and may be subject to revision, but it exists. At some point, the project needs to be released.
That may require some compromises, and it will require some tedium, like signing and provisioning, as well as producing marketing copy and graphic assets. That's part of what you need to do to have shrink-wrapped releases.
A lot of times, I can put off some of the sexier stuff for a 1.1 release.
In many cases; especially where you have heterogenous projects, done by multi-disciplinary teams, dated milestones are pretty much required. You have to have some thing, by some time. I worked like that for many years, as part of massive, multi-national teams.
But these days, I have the "luxury" of generally working alone, or as a member of a casual open-source team that doesn't have any specific deliverable deadlines.
What I do, is define what "done" looks like, and set some very fuzzy milestones. At each of these inflection points, I reexamine the work I'm doing. In some cases, I decide to bin the whole effort, and either rewrite it, or simply scrag it, and move on to the next in the FIFO. In other cases (less often than I'd like), I am ahead of expected schedule, or the functionality of my work is better than expected. Boo-Ya. Go Me.
The important thing for me, is that I have a solid idea of a deliverable. It may not be associated with a date, and may be subject to revision, but it exists. At some point, the project needs to be released.
That may require some compromises, and it will require some tedium, like signing and provisioning, as well as producing marketing copy and graphic assets. That's part of what you need to do to have shrink-wrapped releases.
A lot of times, I can put off some of the sexier stuff for a 1.1 release.