SoylentNews is people
SoylentNews
My father, a Naval officer, was quite fond of shouting "Do something, even if it's stupid!" I expect that, in the heat of battle, indecision is worse than nothing at all.
Back in the day I worked for Dave Johnson's Working Software. We scored a big contract to port Random House Webster's Electronic Dictionary And Thesaurus College Edition - yes that was its real name - from MS-DOS to Mac OS System 7. Included in our contract was $5,000 "Timely Completion Bonus" of which I would receive $3k but only if I completed the work in the allotted time.
I found myself strangely unable to get started. Dave from time to time would politely ask me whether I had, then finally he got very assertive that I should start.
"Look: if you write anything at all, even if it crashes then you can debug it."
I remembered this recently, and it is working well for me. One must not implement too much buggy code or you will never get it debugged, but writing something bad then fixing it may well be better than not implementing anything at all.
(I got my bonus.)
(Score: 5, Interesting) by gman003 on Wednesday April 22 2015, @01:34AM
The two mistakes in your analysis are these:
You assume the entire path can be plotted beforehand.
You assume you can never go backward until the very end.
Not all projects can be perfectly planned. I would say very few can. Many projects are more like battleplans, in that they never survive contact with the enemy. Such projects are full of unknowns, and unknown unknowns.
For such projects, start by building something. The most rudimentary prototype you can make that still has the functional bit that matters.
That tells you what your framework needs, what foundations you need to lay, or for a bigger project, how to architecture the layers. Now start on that. Throw away whatever you need to from the prototype, up to and including the entire thing.
If you come to a point where you realize that the foundation is irreparably flawed, in a way that makes it completely unsuited for the final product, start again. Not just "could be better" or "kinda buggy", and definitely not "ugly style", but actually unusable. Salvage what you can (usually quite a lot more than that first prototype), throw out what you can't, and go at it again.
You may come to such points several times. Each time, the amount you have to throw out should diminish. As long as you're remotely good at your job, you'll be approaching the limit of perfection.
Once you get within a certain distance of perfect, stop throwing things out. Just finish what you have and ship it - spitballing the number, I'd say whenever you're within 10% of your time away from being done, you're at a point of no return. Project specifications also never survive contact with the client. You'll be changing things anyway, so get something to them fast, so they can start telling you what you did wrong. Repeat *that* iteration level several more times.
That's how you manage a project when the customer doesn't know what they need, and you don't know what problems you'll face.
Too much planning ahead of time is a waste, like writing turn-by-turn driving directions when the only map you have is from the Cleveland administration.
Not enough planning is also a waste, for reasons you're obviously well aware of.