I usually plan everything out in excel.
Usually these questions are paramount:
Alarms & Warnings (how many flavors will you have?, Will you have a cripple mode?, Some alarms may shut down the process, others may not.)
Will there be an HMI, and what will be its function? What variables will you give them access to? etc. I usally have a separate subroutine just dealing with the HMI and when using RSLogix500 also a separate set of data files related to the varaibles and operators on the screen.
Manual functions (Will they be latching, momentary, interlocked to prevent damage, etc)
Auto Cycle (Will you require a stepping feature for debug? Will you require a recovery at the point of failure, or will it have to be tooling returned from home each time, will you need a clean out mode?)
I have one tab where I outline all the subroutines I will need.
I have one tab for each subroutine. For each subroutine I type out every single step in plain english, one step per row. I only perform one single operation per step (with rare exceptions). I use integer based sequences, so my steps usually jump by 100. I also jump up to the next 1000 after a sub sequence is complete. This makes additions and modification a breeze. I number my steps as I am typing them.
Most situations can get away with a global watchdog alarm based off a single timer. If the cycle becomes too long I record the step it faulted on and base the fault on that. If I need to perform a check mid sequence, I might dump it to a dead end step just to trigger the watchdog on a unique step value.
I don't write any code until I have a specific step by step written word account of everything that must take place.
I also have a separate subroutine for physical Inputs, where I may debounce them or change the active level.
I also have a seprate subroutine for physical Ouputs where if I change between various modes (Auto, Semi Auto, Manual, etc), and also interlock things together like dual solenoid valves or reversing starters.
Once I have all the sequences written out, I then create the subroutines and then go down through writing the comments into to each network outlining what that network will do.
I go through and comment all the I/O appropriately ahead of time as well. If using RSLogix 500 I will make sure some data files align exaclty to the I/O.
Then finally I go through and write the code. If I take care to keep everything consistent, it may be as simple as copy and paste of the network text on each rung. Never really having to do too much ladder building. For example a typical step will test for a step number, wait for a condition, and then load the next step number once that condition is met. So I could just type this directly in (or CTRL-V from the clipboard), filling in the ? appropriately. EQU ? N7:0 XIC ? MOV ? N7:0 where N7:0 is my StepNumber.
If you have planned everything out well, this stage fast. After you have done it a few times, you will get more accurate with and and find that things tend to work exactly how you layed it out without a lot of code debug.
Put just as much time planning your data files and data organization as you do your code. Well organized data files can really slash development time.
I have always found that every minute of effort invested in the planning stage I get back many fold in the coding and debug time.
Try not to glaze over important details until later. Often you will find that if you haven't accounted for them right from the beginning you end up putting yourself in a corner and you have to re-write code to accomodate it later.
Sometimes it is best to experiment and test your concepts first before comitting them to code. If you are unsure of how something will process, and you will be using that same cocept a lot, you owe it to yourself to test it first.