First things first [entries|reading|network|archive]
simont

[ userinfo | dreamwidth userinfo ]
[ archive | journal archive ]

Wed 2007-06-13 16:57
First things first

In programming, I often find myself faced with a task that has easy bits and hard bits. My usual policy is to tackle the hard bits first, for two reasons:

  • The hard bits are the bits that are most likely to turn out to be actually impossible or infeasible due to some unforeseen wrinkle. So if that's going to happen and the entire project is going to turn out to be doomed, it makes sense to find that out as early as possible so as not to have wasted any more time than necessary.
  • If the easy and hard bits are basically similar in structure, so that their methods of solution are also likely to be similar, then doing the easy bits first runs the risk that as I go along I might develop a standard method which works for them only, and then get a nasty shock when I come to the hard bit and have to work it out all over again. By contrast, it's generally much easier to simplify a method that worked for the hardest bit so that it works for the easier cases, so that way I only have to work out my method once.

So this generally seems like a sensible strategy to me. I've used it for nearly all my programming life: I have a clear memory of advocating it to a couple of schoolmates who were giving programming a try when I was twelve.

Just occasionally, though, it backfires on me. In the past week I've had a task to do with hard bits and easy bits, and of course I did the hard bits first. I beat my head against them for days, and after great effort I'd managed to cobble together something which would probably just about work – and then I suddenly thought of an alternative method which made it all much easier. If only I'd done the easy bits first, that insight could have saved me all the trouble I had with the hard bits. As it was, I had to rip up the mess I made of the hard bits and do them all over again by the sensible method. Bah.

(It is of course possible that I wouldn't have reached the insight in question without the experience gained from struggling with the hard bits, so that the apparent waste of time was unavoidable; but in this particular case I don't think so.)

LinkReply
[identity profile] tackline.livejournal.comWed 2007-06-13 16:10
I tend to prefer to do the hard bits first at a large and tiny level of granularity. At a large scale, I want to pull the risk forward and the hard bits are likely to be those where the requirements are relatively static. At the scale of writing a single method, say, it's just a matter of fleshing out the skeleton after doing the real work. However, somewhere in the middle I like to think. Not directly, just let it stew. Often I will change my mind about how to approach the problem.
Link Reply to this
[identity profile] mtbc100.livejournal.comWed 2007-06-13 16:44
I tend to do hard bits whenever I have mental energy to face them; if I do the easy bits and then the hard bits, I might not have the mental energy at hard-bit-time.
Link Reply to this | Thread
[identity profile] mtbc100.livejournal.comWed 2007-06-13 17:43
Actually, I suppose what I do is I keep doing easy bits that cumulatively make the hard bits easier. (-:
Link Reply to this | Parent
[identity profile] feanelwa.livejournal.comWed 2007-06-13 19:24
To me they are nearly all hard, still :/
Link Reply to this
(Anonymous)Thu 2007-06-14 19:27
The hard bits are where the fun is
I usually go for the difficult parts first, but I think that's mostly because those are the interesting bits. Once all the hard bits are done, all that remains is work :-(


Bob
Link Reply to this
navigation
[ go | Previous Entry | Next Entry ]
[ add | to Memories ]