Goal
The goal of the script is the first thing you should determine. What do you want it to do? If you don't know what you want your script to do, then you will be hard pressed to make anything out of it. Before you ever type anything at all, get a rough idea of what you want to achieve with your script, and then go looking for Conditions, Events, and Commands you think could be useful in doing it. Once you have determined your goal you're ready to determine its feasibility.

Feasibility
There are plenty of things that can be done with scripts, but there are plenty more that cannot. Affecting units on the campaign map in a specific way is not possible, and the options to kill/spawn/etc. units require some very general considerations that don't fit a lot of needs. That's just one of the few. Destroying an individual building in an individual settlement is another, you have to destroy an entire chain in an entire faction to effectively get rid of buildings.

Even some things which are 'feasible', in that they can be done in a roundabout fashion, aren't actually worth doing. One of my concepts for a religious 'points' system which would add fluidity to a very blank religion system by allowing religious conversion to a multitude of religions to take place in every settlement based on the religious buildings constructed, whilst not tying down specific religious building trees to specific religions so they can be re-used by another faction to represent a different religion, is such a case. Suffice it to say that the concept code amounted to somewhere between 200,000 and 2 million lines of code(determined by taking a modular section of the script and multiplying it by the various ways it would need to be changed and replicated to achieve the system), which is a bit much for the script to handle(especially considering how much else I'm adding to it).

So while I know I could make this system, it isn't really worth it. There's a few reasons for this. First is I conceived it before there was ever a script replicator, so it would have been a herculean task at the time. Second is the leverage it provides would not be terribly game changing enough to merit the amount of code it takes. Third and most importantly is while the M2 script is geared better than the Rome script to handle a bunch of lines of code, feeding it tens of millions is bound to cause performance issues, which, again, aren't worth the effect. This is why you need to determine if the time and length of your script idea are worth the effect it will have. Oh and did I mention fourth, that you might have to debug that?

I would say just generally, that if you can't make a script in under 10,000 lines of code, it better be really worth doing and have a noticeably large impact on the gameplay experience. If the script passes your personal feasibility check, you think you can do it and you think it's worth doing, the next step is to concept the script.

Concept
Concept of a script is different than writing the script. Some people like to concept it as they type in bits of it, others prefer to outline it first. There's no right or wrong way. One way to concept a script is pseudocode. You don't have to write out the entire script or even an entire modular piece to get an idea of what it might look like. Here's a short example of some pseudocode:

monitor_event FactionTurnEnd FactionIsLocal
and sewage counter higher than happiness counter
and doesn't have public works buildings
increase the settlement turmoil, need one for each settlement
percent chance for small rebellion
end_monitor

Now pseudocode is not always that pseudo, sometimes it just consists of writing a couple working examples and then a commented line saying it needs to be done for the rest of X. You can see obviously that is not real code, but it eludes to real code and gives the code that will take its place form and structure. Furthermore it actually wouldn't work in that exact setup(did you catch it?), because if we're looking for public works buildings in a settlement then we need to tie it to a SettlementTurnEnd and make separate monitors for each settlement(there's also clunkier methods which allow you to use if statements and counters).

A good concept helps you make sure you don't do needless work only to find the setup is haphazard. Be careful not to allow to much scope creep though, you'll be tempted to add a bunch of features inside features on top of features, which is good, but it has to stop somewhere.

Actualize

Take your concept and write the code. If you wrote the code in a proper modular function, which is to say that you understand the kind of things which are copies of earlier sections with a few parameters changed, then you will find it easier to work with the Script Replicator. Make sure to run the game after each implemented section of the code, and input values that you might change in the long run but you need in order to see that it is working as intended(firing a historic event if you need to monitor something going on behind the scenes to insure it happened is never a bad idea, but don't forget to remove it later on!).

Take care not to manually replicate sections of the code that can be automated. Follow the instructions about using the Script Replicator(coming soon); insuring you utilize it wherever possible helps save you headache and heartache, not to mention time. Remember to comment, comment, comment, and comment some more. I can't tell you how many times I've had to read my own notes about a script I've written because it had so many elements acting on each other and it had been so long since I'd messed with it. And also don't worry to much about whether you have the most sleek and effective method for doing something. Some times you'll find the quickest and most effective route to your goal on the first try, but more often you'll accrue more scripting knowledge in your travels and be able to come back and refine your old scripts to make them utilize more versatile structure or elements.

If you're new to scripting it can't (usually) hurt to try building your script on a blank script first(I say usually because some mods may break if their script is removed), to insure any problems you may come across are caused by your script alone, and any problems you may come across when adding it to a functional script are thus due to conflicts. There will also be times when problems defy all logic, so if you can then just move on to something else and come back to it later. Just the other day I had 5 lines of code that weren't working when they should have, and were working when they shouldn't have, but after wrestling with it for a while I moved on to other scripts and had no problems.

Test & Refine

By far the most boring part of scripting, and coding in general, is the testing. A reasonably complex script usually involves enough contributing factors or random elements that you can't determine if it is doing everything you told it to do in its final form without testing it extensively. To make testing easier it's important to verify the integrity of each section when writing the code by for instance removing random chance and producing easily identifiable results, so you know all the functions are working and will continue to work albeit more sparingly when you add back the chance and get rid of the indicators(assuming you do so without syntax/spelling problems).

Most of the time you aren't going to have a bunch of "I can't mod but I want to help and mean business" types to do your testing for you. If you do then it's your job to tell them exactly what the script should be doing and what they need to do to trigger it. It helps if you also determine any shortcuts, such as console commands a player can use from the (~) shell to speed up a process by processing the construction queue, adding money, or a variety of other things. You may also be able to speed up some of your scripts by temporarily providing a version that has counters set previously or better yet counters which can be toggled by performing a simple task like clicking a button on the interface. Keep in mind though when circumventing parts of the script that you are not testing those parts, so should insure they won't be the problem.

Once your script has been tested and works, either by you, your mod teammates, or a beta testing team, it's time to balance it. The likelihood of getting it exactly right the first try is pretty slim. If you're making a garrison script you'll probably start it to strong or to weak, the player might be given a bit to much money by one script and you need to tone it down unless they swell, or conditions you set to trigger your script might have been a bit to stringent. These are all determined through testing and reporting results, which enables you to refine the script into a truly completed form.