Technology

Computer Programming

Languages Skill Subgroups Skill Modifiers Software Development Hacking
 
 
 
SOFTWARE DEVELOPMENT
Computer Programming allows the creation of Programs, but very little coverage on how difficult or how long it takes to create a particular Program is presented in the official HERO System rules. And for the most part, from the perspective of dramatic relevance, Computer Programming can (like so many other things) reasonably occur at the speed of plot, which is to say it takes whatever amount of time makes for the best story. Still, it is occasionally useful for a GM to have some kind of gauge of how long it should take to do something, for consistency if nothing else. The below chart provides some "rule of thumb" measurements to assit a GM in this task, and detailed exposition follows.
SOFTWARE DEVELOPMENT CONSIDERATIONS
DEVELOPMENT SCOPE TIME
Major Software Release 6 Months to 2 Years
Major Version Release 3 to 6 Months
Minor Version Release 1 to 3 Months
Virus 1 Day to 3 Months
Utility / Applet 1 Hour to 1 Month
Script 5 Minutes to 1 Day
RESOURCE FACTORS EFFECT *
Excellent General Design Decrease Time and
Increase Quality
Real Experts On Team Decrease Time and
Increase Quality
Good People Pool Decrease Time or
Increase Quality
Time To Do It Right Increase Quality
Well  Managed Decrease Time or
Increase Quality
Poorly Managed Increase Time or
Decrease Quality
Insufficient Time Decrease Quality
Insufficient People Increase Time or
Decrease Quality
Insufficient Skillsets Increase Time and
Decrease Quality
Poor General Design Increase Time and
Decrease Quality
* All Effects are cumulative
 
In the real world Software design is a complicated, expensive process with many different scales and scopes of work and few people outside of the sortware industry have any real idea of what it takes to deliver a quality piece of software in a given timeframe. There are literally dozens or more factors to take into consideration, people to manage, skill sets to utilize, contingent deliverables, and deadlines to make.
However, while it is very difficult to accurately predict how long it will really take to develop something new or how good it will be in the end, there are two basic factors that have a very significant impact and that can be taken into account as a useful rule of thumb: the scope of work and available resources.
SCOPE OF WORK
In software development, the scope of work describes the work to be done in detail and specifies the hardware and software involved and the exact nature of the work to be done. In short, it is the definition of what has to be done and is what timelines, budgets, and deliverables are founded upon. Work is typically described as "in-scope" and "out-of-scope", meaning that the work either is accounted for and required, or is being done in addition to the agreed upon work, usually at extra expense and chance of throwing off the timeline.
SCOPE CREEP
Scope creep is the term used to describe the phenomena of the nature of the agreed upon work changing (and typically growing) as the project progresses. This results in many bad things, most typically a "moving target" for deliverables, but also confusion, slipped deadlines, and unintended side effects due to late changes being incompatible or inefficient with design decisions made in the beginning from the original scope of work. There are many causes of scope creep, but in the end it is a sign of weak or bad management of the software development effort. To represent the effects of this, use the "Poorly Managed" line item in the chart above.
AVAILABLE RESOURCES
In software development, available resources include tangible things like physical hardware, infrastructure, and people, as well as intangibles such as time, relevant skills sets, talent, and competencies. Some resource gaps can be overcome by taking more time to do something, or don't prevent completion of work but are reflected in inferior quality, but others are critical and can cause a software development process to fail outright. As a rule of thumb if there are three or more detriments to the project when using the chart above, it is safe to assume that the project fails at some or all levels as a whole regardless of whether discrete parts of the intended system are functional.
TIME AND QUALITY ADVISOR
The time and quality chart first defines some relative software development scope of work complexities and attributes timeframes to them. Thereafter a list of complicating and facilitating factors is listed that indicate the overall affect on the project that is likely to be caused by those factors. By determining the scope and identifying some of the factors, it is very easy to arrive at a reasonably accurate estimate of how long it would take and what the resulting quality of the product is likely to be.
For instance, to write a Utility might take dedicated effort of anywhere from a day to a month (or more) depending on its complexity. If the GM were to determine that it will take three days of development based upon the nature of the software under development, and the programmer's skill set is lacking in regards to what they are trying to write, the GM can reasonably determine that it's going to take the developer longer to muddle through it and the product is likely to be of lesser quality. Similarly, if its really a job for three people being done by one then the GM could reasonably determine that the resulting software might take even longer to write, or be even worse than it otherwise would have been.
It is important to note that the time and quality factors makes no mention of actual skill rolls. It is not intended to replace the general usage of Computer Programming in other sections; rather it is merely a rule of thumb for GM's to help them make and consistent decisions about how long it takes to create software.
Also, the time and quality factors is from the perspective of a development team in a corporate environment, and some of the line items are not relevant to lone-wolf or "cowboy" coders that are hacking out software on their own to suit whatever purpose they have in their own minds. Most player characters are of this later type, but the chart can still be used with the application of judgment on the part of the GM. Generally speaking there is a trade off between all the overhead and management involved in corporate development that represent drag that doesn't affect a person coding on their own or with a small group of friends in a non-corporate environment, but on the other hand all the little touches and "extras" necessary to turn out a professional looking and robust piece of software generally are outside the realms of non-corporate development.