Computer Programming

Languages Skill Subgroups Skill Modifiers Software Development Hacking
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 for 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.
The following chart categorizes software development in general sizing terms and gives a default base time to produce a releaseable version of features and / or fixes of that size; for instance a minor release for existing software has a much smaller scope of work than building the first version of a non-trivial application or platform.
The following chart assumes a "professional" level of quality of basically working software that satisfies its primary purpose with no major bugs; but that might be missing a few minor features or have a few minor bugs (of the quirks or glitch variety). A lower quality release will have significant bugs, and / or narrower functionality, and / or poor ux or integration options, and / or basic engineering flaws such as leaked resources, instability, security holes, and so on. Higher quality software will offer a richer feature set, and / or be entirely bug free, and / or have excellent ux or "just works" integration options, and / or exhibit optimal engineering qualities such as efficient resource consumption, hardened security, impressive speed of execution, and so on.
New Software Release 1 Year
Major Version Release 3 Months
Minor Version Release 1 Month
Virus 3 Months
Utility / Applet 1 Day
Script 6 Hours
Excellent General Design Decrease Time and
Increase Quality
Real Experts On Team Decrease Time or
Increase Quality
Time To Do It Right Increase Time and
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
Leveraging Existing Components Decrease Time and
Decrease Quality
Derivative / Routine Decrease Time or
Increase Quality
Cutting Edge Increase Time or
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 software 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, funding issues, and generally unrealistic deadlines forcing many non-optimal trade offs.
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.
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 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.
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.
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.
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 consistent decisions about how long it takes to create and enhance 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 industrial grade and robust software generally requires some kind of larger organizational infrastructure (though some exemplary open-source development efforts challenge that assumption).