views:

230

answers:

9

David Allen's "Getting Things Done" recommends keeping a "Next Action" list to organize your work, where a "Next Action" is the next physical action you will do to make progress towards an objective.

In programming, determining what to do next is often almost as hard as doing it (sounds like the halting problem). Most of the work is examining the program to determine where and how to modify the code in order to achieve some objective. Physically writing code is the easy part. Once you know what to do, why stop to describe it when you could try it in a few minutes?

Is the next action list a useful way to organize programming work? If so, how would you define your next action? If not, how else would you organize what you are about to do?

There is a related question here.

+1  A: 

A very strange question really.

Why would you need to describe what to do for yourself? Once you know, you just do it. That's the point of job, make it work.

I find that such studies and abstract strategies only complicate things. When you are fit for the job, you just do it without any "next actions" lists, scrums, time estimations etc.

If you can't just do it without the entourage, you are probably not fit for the job.

If they don't let you keep things simple, check out maybe you leave them alone and go somewhere else where the things are just get done.

User
+4  A: 

The secret is to start. Once you stared it will be done.

AraK
But suppose you finish, and you forgot what to do next? :)
Evan Rogers
Priorities are clear in our mind, we just don't wanna start :)
AraK
+1  A: 

If you follow Test Driven Development principles, you'd effectively define what you're going to do by writing unit tests which will be failing to start off with as you haven't yet changed the code to get it to behave as you need to.

These unit tests effectively document what you need to achieve.

A blog I was reading recently suggested a good way to solve the problem where you come back to some code after a break (e.g. between working days) and have to work out exactly where you got to by skimming back over your code, is to always leave it failing on a test - that test then marks where you got to.

AdaTheDev
TDD usually doesn't test documentation and I've never seen it used to test if the code actually got deployed on the production.
Tadeusz A. Kadłubowski
@tkadlubo - I'm not sure what you're saying/if you've understood what I meant. I wasn't saying TDD tests documentation, or that it tests if code gets deployed.
AdaTheDev
I meant that there are many more actions that making the tests pass.
Tadeusz A. Kadłubowski
+4  A: 

I like to keep a list with things I have to do. Not in an ordered fashion but something where I can store all the things I stumble upon but I don't want to do right now to not get distracted.

Having a small list with the things that are left maybe with a time estimation gives you a plan, something to hold on to and the confidence that you are on track.

Even if you are working somewhere with a bug tracker and ticket system there are things you see in the code you know you have to change it but it is to small for a ticket and to big to get it done at the moment.

Janusz
+4  A: 

Yes. I think that it helps a lot.

Some pros:

  • It helps getting on track after distractions
  • It verbalizes your thinking about what needs to be done
  • It helps you manage all the loose ends that will need to be taken care of
  • It integrates with quality checklist
  • It makes progres reporting much easier

As how to determine next actions: it's really a metter of personal preference, skill, confidence etc. I think that one should not hesitate to make it rather verbose. Think in terms of how the situation would look like if you were done.

Tadeusz A. Kadłubowski
I don't like to do such, as distractions can actually help you take a step, get out of that particular train of thought and find the solutions.It depends on the level on which you would write things down, though. There's a whole lot of difference between "thing x needs to be done, so I'll do that (add some functionality)" and "I'll do x, so I can advance in thing y, which will then led me get that functionality added"
Jasper
@Jasper: Too much distractions quickly suck all of your productivity. If they happen often, then the speed of getting back in zone is essential.
Tadeusz A. Kadłubowski
I think the verbose recommendation can be bad. The book Code Complete recommends a balance. Having no descriptions means that you have to read through all your code to remember what you're doing, which won't scale. Describing your code in full detail makes the description just as hard to read as the code. Descriptions of code should be concise summaries, and sometimes many levels of detail is necessary.
Evan Rogers
A: 

I've noticed some people over think the planning stages of development.

Sure, some planning is needed but it doesn't need to be so formalized. Try different things and see how well they work out. Some people can write great software from some plans they scribbled out on a napkin at 2a.m. while eating waffles.

... mmm waffles.

Anyway the point is don't over think it. Make some plans and if they turn out to not be enough plan some more on the next project.

Spencer Ruport
+1  A: 

I strongly believe in keeping a task list. You so much less prone to 'forget' to do this ugly, boring thing that needs to be done until tomorrow, when you have a list to remind you of it.

If you are only coding, that may not be necessary. But in my experience, there are always other things that need doing as well:

  • Updating a spreadsheet, how many hours you worked on this or that project
  • Filling out some forms for the HR guys
  • Preparing a project status report
  • Writing the documentation for this horrible class from last week
  • Dealing with a customer complaint that somehow landed on your desk

So yes, definitely go for the list. Not necessarily for the work of writing one module, but for all the other stuff besides coding this module, that needs doing.

Treb
+2  A: 

Once you know what to do, why stop to describe it when you could try it in a few minutes?

Sometimes what one thinks will be done in a few minutes can end up being days if not weeks because of "just a little thing here and there" that isn't so little in the end.

Is the next action list a useful way to organize programming work?

I think it can work if one has the discipline to stick with it and have the habit stick.

If so, how would you define your next action?

I'd define it as the next step to do and what result should I have to know it is done. This could be as simple as knowing what class I'm creating or what tests I want to put onto something. It can also be useful sometimes to be able to go back and look at what else was on the list when one wants to do something else if one gets blocked by a bug.

JB King
+1  A: 

I think that a "next action" is implicit..

personally I keep a TODO list with different sections and different priorities. I write there everything I have to do, and then simply pick something and do it!

luca