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, Insightful) by tftp on Wednesday April 22 2015, @12:33AM
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.
Often that leads to building a tall tower on bad foundation. Eventually you realize that the whole codebase needs to be scrapped and rewritten. Better to spend time on thinking and planning before you initiate an avalanche of bad decisions. Besides, thinking is much cheaper than coding.
(Score: 5, Funny) by bob_super on Wednesday April 22 2015, @12:53AM
You're 100% right, and I start following your advice tomorrow.
(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.
(Score: 5, Insightful) by sigma on Wednesday April 22 2015, @04:03AM
Often that leads to building a tall tower on bad foundation. Eventually you realize that the whole codebase needs to be scrapped and rewritten. Better to spend time on thinking and planning before you initiate an avalanche of bad decisions.
While it's true you have to to avoid the Tall Tower on Bad Foundations or you'll end up with an Avalanche of Bad Decisions, just saying so isn't helpful. What you have to have is a way to invoke the Panic Monster early, and banish the Instant Gratification Monkey to the nearest tree. If you don't, you'll just end up in the Dark Playground or Mixed Feelings Park.
In other words, what you really need to do is identify the Critical Entrance early, and head straight for the Tipping point.
Or you could procrastinate a little longer and read this [waitbutwhy.com]. Don't forget to follow the link to Part Two...
(Score: 2) by mhajicek on Wednesday April 22 2015, @06:46AM
I wuz gonna post that but I didn't get around to it.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 4, Insightful) by davester666 on Wednesday April 22 2015, @08:34AM
Except the thing you really want to do is:
Ship that stinking pile of crap. Then you get your cheque and they think you are wonderful for actually getting the job done.
Now, hello Maintenance Contract...
(Score: 2) by Magic Oddball on Wednesday April 22 2015, @10:00AM
Sad to say, that's the approach that seemingly all of the so-called gardening companies, tree specialists, and supposed arborists in my area take. They took advantage of the influx of newcomers from major cities or extremely dry areas, and got it so the "in" thing is to remove all of the fucking limbs from fruitless mulberry trees & other 'shade' species. Since all that's left is a tall stump that sends out shoots in all directions, they now can charge the same amount to spend an hour every year denuding the stump from a stepladder that they normally would charge every 2-3 years to spend an entire morning carefully removing select excess branches from high inside a big healthy tree.
(Score: 1) by letssee on Wednesday April 22 2015, @08:50AM
>Often that leads to building a tall tower on bad foundation. Eventually you realize that the whole codebase needs to be >scrapped and rewritten. Better to spend time on thinking and planning before you initiate an avalanche of bad decisions. >Besides, thinking is much cheaper than coding.
You know the saying 'be prepared to throw the first one away!' ? For all but trivial projects it is impossible to think everything through in advance. Trying to do so leads to feeling incapable of completing the huge task, and thus procrastination.
Build prototype. Learn from it. Build the real thing (re-using the good parts from your prototye).
If you make your code modular, starting again does not mean starting from scratch!
'first think things through before starting' is the worst advice I heard in ages.
(Score: 2) by mr_mischief on Wednesday April 22 2015, @07:05PM
The surest way to build a high tower on a shaky foundation is to plan the whole thing before testing the ground.
Thinking all the way through something without checking one's assumptions of how things will work is careless. Having a general idea ahead of time is good, but one must be ready and able to adapt to conditions. There is no finishing the job without starting it, and quality cannot be bolted on at the end. Building something of value is about knowing how and when to change the plan as much as how to write the plan.