HOW TO REDUCE PROGRAMMING TIME
by Gary Astleford
Print this Article
  print

Many 'runners complain that they despise the time it takes them to sit down and write a program. The truth is, though, that only one-third of the time spent writing a program is actual code entry. You can't just sit down and write a program and expect it to work perfectly the first time you run it. It takes time to work out all the bugs. I figure that at least 2/3rds of the time spent on "writing" a program is testing it to make sure it does what it's supposed to do. These "beta" versions do end up on the street, though they are usually defective in some way.

Now, someone who wants to write a program speedily can do so in DIFF x 2 hours. They will have a workable program to screw around with. However, without proper testing, the program is liable to be rife with bugs. The first time you install it, you must roll on the following chart to see what happens. Assume the same malfunction occurs with every other copy of the program until it is debugged.

BETA VERSION MALFUNCTION CHART

Roll 1d10 (plus any modifiers) -

1	Program runs without a hitch (you got lucky).
2	Program locks up 50% of the time.
3	Program will derez if it fails a success roll.
4	Program's STR is reduced by half, rounding down.
5	Program takes 1d6 turns to load.
6	Program takes up twice as much MU.
7	Program is slow, and reduces Deck Speed by -3.
8	Program runs perfectly, it seems, but doesn't do anything (ie, all rolls automatically fail).
9	Program won't run.
10	Roll twice more, re-rolling in the case of a 1 or 10 result.

Say you want to debug it, but you don't want to take as long or be as thorough. Fine, no sweat. Use the following modifiers on the Beta Version Malfunction Chart, depending on the extra time you took past the Difficulty x 2 you spent writing it:

DIFF x 1 Hours Debugging : -3 on the chart.
DIFF x 2 Hours Debugging : -5 on the chart.
DIFF x 3 Hours Debugging : -8 on the chart.
DIFF x 4 Hours Debugging : -10 on the chart (ie, don't even bother rolling).

If a program is defective, it can be debugged by taking the extra time required to debug it and making a Programming roll equal to the program's difficulty.

EXAMPLE -

Matthias (Int 8, Programming +5) needs to churn out a quick wall buster akin to Termite, but doesn't want to take the time debugging a program that he'll probably only use once. The program has the Intrusion function (diff 15), a simple icon (diff 1), is one-use only (-10), and wields a program strength of +4 (diff 4), for a total difficulty of 10 (15+1+4-10=10).

Matthias can churn out the program in 20 hours (difficulty x 2 hours). He decides that 10 more hours slaving over this little program won't hurt, so he debugs for 10 hours. He must roll on the Beta Version Malfunction Chart with a modifier of -3 to see if the program has any bugs. He rolls a 9, modified for his 10 hours of debugging by -3, equaling a 6. Something in the code is clunky, and causes the program to take up twice as much space (base MU of 1, doubled to 2). Matthias feels this is a small price to pay, and takes the program out for a spin.

What's New Guns and Weapons Gear and Equipment Cybernetics and Implants House Rules Netrunning and Net Gear A Day in the Life Recommended Dosages Names and Faces The Man Cyberpunk Sites Wheels and Otherwise Copyright and Legal Statements Out on the Town